web-dev-qa-db-ja.com

WebSocket通信に対するCSRF攻撃の防止

WebsocketでのCSRF攻撃に関するスレッドを読んだ（ WebSocketを使用したWebアプリ（例： "comet"アプリ）はCSRFを心配する必要があるか？ ）。また、websocketのセキュリティに関するいくつかの資料を読んだ彼らは次の問題に対処しているようです-

攻撃者が（被害者にリンクを押すよう誘導することにより）正当なユーザーに正当なサービスに向けてWebSocketを開かせたり、被害者の既存のWebSocket内で攻撃者が作成したメッセージを送信したりすることは可能ですか？ （HTTPのコンテキストでの標準的なCSRF攻撃に似ています）。

可能であれば、それを防ぐために何ができますか？ WebSocketを開くときにWebSocket URLでトークンを十分に送信していますか、それともWebSocket内で送信されるすべてのリクエスト内でトークンを送信する必要がありますか？

私たちはWebSocketを使用して、サイトの認証されていない領域にチャットを実装するつもりであり、悪意のあるユーザーが上記のような攻撃を実行するのを防ぐためにできる限りのことを行いたいと考えています。これを実装する最も安全な方法に関する特別な推奨事項はありますか？

web-applicationcsrfhtml-5websocket
7
user3074662

認証Cookieに依存している場合、WebSocketに対するCSRF攻撃が可能です。 RFC 6455§1.3から：

|起源|ヘッダーフィールド[RFC6454]はnauthorized cross-Origin WebSocketサーバーの使用scripts WebSocket APIの使用Webブラウザーでから保護するために使用されます。サーバーには、OriginがWebSocket接続要求を生成するスクリプトが通知されます。サーバーがこのオリジンからの接続を受け入れたくない場合、[拒否することを選択できます適切なHTTPエラーコードを送信して接続を行います。このヘッダーフィールドは、ブラウザクライアントによって送信されます。非ブラウザクライアントの場合、これはheaderフィールド送信される可能性がありますそれらのクライアントのコンテキストで意味がある場合。

いくつかの部分を強調しました。最初の魔法の言葉は缶であり、2番目は5月です。 WebSocketサーバーcan Originを確認しますが、これはオプションです。ブラウザ以外のクライアントmay Originヘッダーを送信しますが、これは必須ではありません。

悪意のある攻撃者はCSRF攻撃を使用してWebSocketサーバーへのWebSocket接続を開くことができ、Cookieはブラウザによってリクエストに追加されます。サーバーがオリジンをチェックしない場合、またはオリジンをチェックしたがオリジンが偽造されている場合、攻撃は被害者の権限を持つWebSocketサーバーへの読み書きトンネルを取得します。

人間は伝統的に正しいOriginヘッダーを送信する主要なブラウザーを使用しているため、Originをチェックすることでおそらく攻撃の大部分をカバーできます。ただし、「偽の|送信元|ヘッダーフィールドを送信し、サーバーを誤解させる可能性がある」[RFC 6455§10.1]のような非ブラウザクライアントに直面すると、他のメカニズムを適用する必要があります。 。 このブログ投稿 は、オリジンを確認することと、対策としてセッション固有のランダムトークンを使用することの両方を提案しています。使いやすさを損なう可能性がありますが、確立後、WebSocket接続を介して何らかの認証を実行することもできると思います。

4
Daniel

以下の私の回答は、Originヘッダーが正しくチェックされていることを前提としており、具体的に質問に回答しています。

新しいWebソケットを開くときに、Originチェック、または独自のコードで行われた他の有効な認証チェックがない場合、ソケットハイジャックが可能です。

元の答えは次のとおりです...

攻撃者が（被害者にリンクを押すよう誘導することにより）正当なユーザーに正当なサービスへのWebソケットを開かせたり、被害者の既存のWebソケット内で攻撃者が作成したメッセージを送信したりすることは可能ですか？ （HTTPのコンテキストでの標準的なCSRF攻撃に似ています）。

いいえ、攻撃者は新しいWebソケットを開いたり、被害者の既存のWebソケットを再利用したりして、WebソケットでCSRFを実行することはできません。

新しいwebsocketを開くことにより：攻撃者はこれを行うことができますが、ソケットリスナーに認証資格情報を提供するメカニズムはありません。最初のハンドシェイクHTTPリクエスト中に、Originヘッダーをサーバー側で使用して、これが有効なOriginからのものであることを確認できます。ソケット自体については、通常のHTTP要求とは異なり、デフォルトではユーザーを識別または認証するためにブラウザーから送信されるヘッダーはありません。

被害者の既存のWebソケットの再利用：Webソケットがwww.example.comのホームページでそのように宣言されているとしましょう。

var exampleSocket = new WebSocket("ws://www.example.com/socketserver", "protocolOne");

www.example.comのDOMへのアクセスは Same Origin Policy によって保護されているため、攻撃者はexampleSocketへの参照を取得できません。

2
SilverlightFox