1. ホーム
  2. javascript

[解決済み] なぜWebSocketにはsame-originポリシーがないのですか?なぜ、ws://localhostに接続できるのでしょうか?

2023-04-12 10:58:28

質問

アプリケーション(Daemon<->WebGUIとDaemon<->FatClientなど)のプロセス間通信にWebSocketを使用したいのですが、どうすればよいでしょうか?テストでは、websocket.orgのJavaScript WebSocketクライアントを通じて、ローカルで動作しているWebソケット・サーバ(ws://localhost:1234)に接続しようとしました( http://www.websocket.org/echo.html ).

今の私の疑問は

なぜこのようなことが可能なのでしょうか? ブラウザ(ここではLinuxのFF29)にクロスオリジンポリシーが実装されていないのでしょうか?

私が尋ねているのは、もしwebsocket.orgが邪悪であれば、それは私のローカルWSサーバーと通信しようとし、localhostから受け取るすべてのメッセージを他のサーバーにリダイレクトすることができたからです。

ローカルWebSocketサーバーブラウザ邪悪なWebサーバ
at ws://localhost:1234 at http://evil.tld
        | | |
        | |------[GET /]--------->|。
        | |<-----[HTML+EvilJS]------||...
        |<------[connect ws://...]----|||。
        |<----[何らかの通信]-->||||。
        | |-----[邪悪な前方]---->|。
        



使用例全体をテストしたわけではありませんが、websocket.orgによって配信されたJSからws://localhostへの接続は間違いなく動作します。

どのように解決するのですか?

なぜ?"の部分について説明すると、ブラウザが AJAX 呼び出しとは対照的に WebSocket に対して Same Origin Policy (CORS はその緩和策) を実施しない理由は、WebSocket がクロスオリジン リクエストの価値が確立した後に導入され、そもそも SOP に従わないため、CORS クライアントサイド チェックの歴史的理由が適用できないからです。

AJAX については、包括的な単一起点ポリシーの時代には、サーバーは認証されたブラウザーが異なるドメインからリクエストを送信することを予期しませんでした。

1 そのため、リクエストが信頼できる場所から来ることを確認する必要はありませんでした。 2 であり、セッション Cookie をチェックするだけでよかったのです。CORS のような後の緩和では、クライアントサイドのチェックが必要で、それは 既存のアプリケーションを悪用することを避けるため を悪用する既存のアプリケーションを公開しないように、クライアントサイドのチェックが必要でした (事実上、この前提に違反して CSRF 攻撃 ).

もし今日Webが発明されたとしたら、私たちが今知っていることを知れば、SOPもCORSもAJAXには必要なく、すべての検証はサーバーに任されている可能性があります。

WebSocket は新しい技術であり、最初からクロスドメインシナリオをサポートするように設計されています。サーバー ロジックを書く人は誰でも、クロスオリジンリクエストの可能性を認識し、CORS のようなブラウザ側の強引な予防措置は必要なく、必要な検証を実行する必要があります。


1 これは単純化したものです。リソースに対するクロスオリジンの GET リクエスト (<img>, <link> および <script> タグを含む) とフォーム送信の POST リクエストは、Web の基本機能として常に許可されていました。今日では、同じプロパティを持つリクエストのクロスオリジンAJAXコールも許可されており、次のように知られています。 単純なクロスオリジンリクエスト . ただし、サーバーの CORS ヘッダーで明示的に許可されていない限り、このようなリクエストから返されたデータにコードでアクセスすることは許可されません。また、サーバーが悪意のある Web サイトから身を守るためにアンチ CSRF トークンが必要な主な理由は、このような単純な POST リクエストにあります。

2 実際、リクエストのソースをチェックする安全な方法は Referer ヘッダは、例えばオープンリダイレクトの脆弱性を使ってなりすますことができるためです。これはまた、当時 CSRF 脆弱性がどれほど理解されていなかったかを示しています。