Originヘッダーは本当にWebSocketを保護するのに役立ちますか？
私はWebSocketsのセキュリティに関するいくつかの投稿を読んでいますが、そのうちのいくつかは、接続を保護するためにOriginヘッダーを使用することについて言及しています。たとえば、これは https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html です。
しかし、私はそれが提供するであろう利点について本当に疑っています。 Originヘッダーを使用する必要があるのはなぜですか？あるいは、何か役に立つものにOriginヘッダーをどのように使用すればよいでしょうか。
Originヘッダーを確認すると、ユーザーがアクセスしている別のWebサイトでWebSocketが使用されなくなります（データの抽出など）。
リンク に従って：
WebSocketは同一生成元ポリシーによって制限されていません
これは、プロトコルアップグレードリクエストがユーザーのCookieにアクセスできるため、Originを確認しない場合、リクエストはexample.comではなく、サイトexample.net。
例えばプライベートデータを返すWebSocketサービスがある場合、ユーザーがログインしているために、ユーザーが悪意のあるサイトにデータを読み取らせないようにする必要はありません。
他のウェブサイトがあなたのウェブサイトからコンテンツをリーチングするのを止めることとは何の関係もありません-彼らがそうしたければ、彼らは彼らのバックエンドからあなたのソケットウェブサービスへの接続をセットアップし、そこで彼らは彼らが望むどんなOriginヘッダーも設定することができます。 Originヘッダーを確認すると、バックエンドでユーザーの認証CookieをWebサービスに提供できないため、認証されたコンテンツについてこれを停止します。
もちろん、ユーザーを登録し、バックエンドHTTPクライアントを使用して、そのための認証Cookieを送信することもできます。ただし、アクセスするのはエンドユーザーのデータではなく、自分のデータのみです。特定のユーザー名またはリモートIPがパブリックコンテンツの多くを引き下げているかどうかを検出して、ユーザー固有ではない可能性があるサービスの機能の使用を防ぐことができます。
Originヘッダーを使用すると、別のWebサイトがwebsocketサービスをユーザーに公開するのを防ぐことができます。
www.example.netの比較的興味のないHTML + Javascriptクライアントで構成されるWebアプリケーションを構築し、ws.example.netのWebSocketを介してはるかにエキサイティングなサーバーバックエンドからデータを受信するとします。
これで、誰かが独自のWebサイトwww.example.comを作成し、html + javascript側を複製しますが、ws.example.netに接続しています。そのため、ユーザーの許可なくサーバーの容量とデータをユーザーにリーチさせることで、サーバーバックエンドのメリットを享受できます。あなたはそれが好きではありません。
あなたは何ができますか？
他のWebサイトのユーザーからのすべてのWebSocket接続にはOrigin:example.comがあり、自分のWebサイトからの接続にはOrigin:example.netがあります。これにより、自分の訪問者からの接続のみを受け入れることができます。
ただし、OriginヘッダーはWebブラウザーによって設定されることに注意してください。ユーザーがウェブサイトを経由していないときでも、サービスに接続するためにそれを操作する可能性があります。また、偽のOriginヘッダーを使用してWebSocketサーバーに接続する非ブラウザーアプリケーションを誰かが作成して配布する可能性もあります。 Originヘッダーをチェックすることは、使用するはずのないバックエンドを使用していることに気づいていない不幸なインターネットユーザーによる大量虐待を防ぐだけです。