WebSocketに同一生成元ポリシーがないのはなぜですか？なぜws：// localhostに接続できるのですか？

Question 1

アプリケーションのプロセス間通信にWebSocketを使用したい（Daemon <-> WebGUIおよびDaemon <-> FatClientなど）。テスト中に、websocket.org（http://www.websocket.org/echo.html）のJavaScript WebSocketクライアントを介してローカルで実行されているWebソケットサーバー（ws：// localhost：1234）に接続しようとしました。

私の質問は今です：
なぜこれが可能ですか？ブラウザ（ここでは：LinuxのFF29）にクロスオリジンポリシーが実装されていませんか？

websocket.orgが悪かった場合、ローカルWSサーバーと通信して、ローカルホストから受信したすべてのメッセージを他のサーバーにリダイレクトしようとする可能性があるため、私は尋ねています。

ローカルWebSocketサーバーブラウザ邪悪なWebサーバー
ws：// localhost：1234、http：//evil.tld
        | | |
        | | ------ [GET /] ---------> |
        | | <----- [HTML + EvilJS] ---- |
        | <------ [connect ws：// ..] ---- | |
        | <---- [いくつかのコミュニケーション]-> | |
        | | ---- [邪悪な前進] ----> |
        | | |

ユースケース全体をテストしたわけではありませんが、websocket.orgによって提供されるJSからws：// localhostへの接続は確実に機能します。

Question 2

「なぜ？」に対処するため部分的には、ブラウザーがAJAX呼び出しではなくWebSocketに同一生成元ポリシー（CORSは緩和）を適用しない理由は、クロスオリジンリクエストの値が確立された後にWebSocketが導入されたためです。そもそもSOPの対象ではないため、CORSクライアント側チェックの歴史的な理由は当てはまりません。

AJAXの場合、包括的な単一生成元ポリシーの時代には、サーバーは認証されたブラウザーが別のドメインからリクエストを送信することを期待していなかったため¹、リクエストが信頼できる場所からのものであることを確認する必要はありませんでした²。セッションCookie。CORSのような後の緩和策では、この仮定に違反することで既存のアプリケーションが悪用されるのを防ぐために、クライアント側のチェックを行う必要がありました（効果的にCSRF攻撃を実行します）。

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

新しいテクノロジーであるWebSocketは、最初からクロスドメインシナリオをサポートするように設計されています。サーバーロジックを作成する人は誰でも、クロスオリジンリクエストの可能性を認識し、CORSのようなブラウザ側の手間のかかる予防策を必要とせずに、必要な検証を実行する必要があります。

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

²実際、Refererオープンリダイレクトの脆弱性を使用するなどしてヘッダーがスプーフィングされる可能性があるため、リクエストソースをチェックする安全な方法も利用できませんでした。これは、CSRFの脆弱性が当時どのように理解されていなかったかを示しています。

Question 3

oberstetは質問に答えました。ありがとうございました！残念ながら、コメントだったので「正解」とは言えません。ブラウザは、アプリケーションで確認できる「origin」ヘッダーを送信します。

Javaの場合[1]：

@オーバーライド
public void onOpen（WebSocket clientSocket、ClientHandshakeハンドシェイク）{
    String clientOrigin = handshake.getFieldValue（ "origin"）;

    if（clientOrigin == null ||！clientOrigin.equals（WEBSOCKET_ALLOWED_ORIGIN_HEADER））{
        logger.log（Level.WARNING、 "クライアントが正しいオリジンヘッダーを送信しませんでした：" + clientOrigin）;        

        clientSocket.close（）;
        戻る;
    }

    //..。
}

[1] https://github.com/TooTallNate/Java-WebSocketを使用する

Question 4

WebSocketはドメイン間通信を行うことができ、SOP（同一生成元ポリシー）によって制限されません。

あなたが説明したのと同じセキュリティの問題は、WebSocketなしで発生する可能性があります。

邪悪なJSは次のことができます。

evil.tldへのURLを使用してスクリプト/画像タグを作成し、クエリ文字列にデータを入力します。
フォームタグを作成し、フィールドにデータを入力して、フォームの「送信」アクションを呼び出し、HTTP POSTを実行します。これは、クロスドメインにすることができます。AJAXはSOPによって制限されますが、通常のHTTPPOSTは制限されません。XSRFWebセキュリティの問題を確認してください。

何かがページにjavascriptを挿入したり、悪意のあるjavascriptを取得したりすると、セキュリティはすでに破られています。