WebSocket Attacks
WebSocketsとは
WebSocket接続は初期のHTTPハンドシェイクを介して確立され、長寿命であり、トランザクショナルシステムの必要なくいつでも双方向メッセージングを可能にするよう設計されています。これにより、低遅延またはサーバー起点の通信が必要なアプリケーションにとって特に有利であり、ライブ金融データストリームなどが該当します。
WebSocket接続の確立
WebSocket接続の確立に関する詳細な説明はこちらでアクセスできます。要約すると、WebSocket接続は通常、以下に示すようにクライアントサイドのJavaScriptによって開始されます:
wss
プロトコルは、TLSで保護されたWebSocket接続を示し、ws
は保護されていない接続を示します。
接続確立中に、ブラウザとサーバー間でHTTP経由でハンドシェイクが行われます。ハンドシェイクプロセスには、ブラウザがリクエストを送信し、サーバーが応答するという手順が含まれます。以下はその例です:
ブラウザがハンドシェイクリクエストを送信します:
サーバーのハンドシェイク応答:
WebSocketの接続は一度確立されると、両方向でメッセージのやり取りが可能なまま開かれたままとなります。
WebSocketハンドシェイクの主なポイント:
Connection
およびUpgrade
ヘッダーは、WebSocketハンドシェイクの開始を示します。Sec-WebSocket-Version
ヘッダーは、通常13
である希望するWebSocketプロトコルバージョンを示します。Sec-WebSocket-Key
ヘッダーには、Base64でエンコードされたランダムな値が送信されます。これにより、各ハンドシェイクが一意であることが保証され、キャッシュプロキシに関連する問題を防ぐのに役立ちます。この値は認証用ではなく、応答が誤って構成されたサーバーまたはキャッシュによって生成されていないことを確認するためのものです。サーバーの応答に含まれる
Sec-WebSocket-Accept
ヘッダーは、Sec-WebSocket-Key
のハッシュであり、サーバーがWebSocket接続を開く意図を確認します。
これらの機能により、ハンドシェイクプロセスが安全かつ信頼性があり、効率的なリアルタイム通信が実現されます。
または、websocatサーバーを作成するには:
MitM websocket connections
クライアントが現在のローカルネットワークからHTTP websocketに接続していることがわかった場合、ARP Spoofing Attackを試して、クライアントとサーバーの間でMitM攻撃を実行できます。 クライアントが接続しようとしているときに、次のように使用できます:
Websockets enumeration
ツールhttps://github.com/PalindromeLabs/STEWSを使用して、websocketsで自動的に脆弱性を発見**、指紋を取得し、既知の脆弱性を検索できます。
Websocket Debug tools
Burp Suiteは、通常のHTTP通信と同様に、MitM websockets通信をサポートしています。
socketsleuthBurp Suite拡張機能は、履歴を取得し、インターセプトルールを設定し、一致および置換ルールを使用し、IntruderおよびAutoRepeaterを使用して、BurpでWebsocket通信をより効果的に管理できます。
WSSiP: "WebSocket/Socket.io Proxy"の略で、Node.jsで書かれたこのツールは、クライアントとサーバー間のすべてのWebSocketおよびSocket.IO通信をキャプチャし、インターセプトし、カスタムメッセージを送信し、表示するためのユーザーインターフェースを提供します。
wsreplは、特にペネトレーションテスト向けに設計された対話型websocket REPLです。着信websocketメッセージを観察し、新しいメッセージを送信するためのインターフェースを提供し、この通信を自動化するための使いやすいフレームワークを提供します。
https://websocketking.com/は、websocketsを使用して他のWebと通信するためのWebです。
https://hoppscotch.io/realtime/websocketは、他の種類の通信/プロトコルと共に、websocketsを使用して他のWebと通信するためのWebを提供します。
Websocket Lab
Burp-Suite-Extender-Montoya-Courseには、websocketsを使用してWebを起動するコードがあり、この投稿で説明が見つかります。
Cross-site WebSocket hijacking (CSWSH)
Cross-site WebSocket hijacking、またはcross-origin WebSocket hijackingは、WebSocketハンドシェイクに影響を与える**Cross-Site Request Forgery (CSRF)の特定のケースとして識別されます。この脆弱性は、WebSocketハンドシェイクがHTTPクッキー**だけで認証する場合に発生し、CSRFトークンや同様のセキュリティ対策がない場合に発生します。
攻撃者は、脆弱なアプリケーションに対してクロスサイトWebSocket接続を開始する悪意のあるWebページをホストすることでこれを悪用できます。その結果、この接続は、セッションハンドリングメカニズムのCSRF保護の欠如を悪用し、被害者のセッションの一部として扱われます。
Simple Attack
websocket接続を確立する際にcookieがサーバーに送信されることに注意してください。サーバーは、送信されたcookieに基づいて各特定のユーザーをwebsocketセッションに関連付ける**ためにそれを使用しているかもしれません。
その後、例えば、websocketサーバーがユーザーの会話の履歴を送り返す場合、msgに"READY"が送信されると、単純なXSSが接続を確立し(cookieは自動的に送信されて被害者ユーザーを認証するため)、"READY"を送信することで、会話の履歴を取得できるようになります。
クロスオリジン + 異なるサブドメインのCookie
このブログ記事https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/では、攻撃者がWebソケット通信が行われているドメインのサブドメインで任意のJavaScriptを実行することに成功しました。サブドメインであったため、Cookieが送信され、WebsocketがOriginを適切にチェックしなかったため、それと通信してトークンを盗むことが可能でした。
ユーザーからデータを盗む
なりすましを行いたいWebアプリケーション(たとえば.htmlファイル)をコピーし、Websocket通信が行われているスクリプト内にこのコードを追加します:
今、https://github.com/skepticfx/wshook から wsHook.js
ファイルをダウンロードし、webファイルが保存されているフォルダに保存してください。
Webアプリケーションを公開し、ユーザーがそれに接続するようにすると、WebSocketを介して送受信されたメッセージを盗むことができます:
レースコンディション
WebSocketsにおけるレースコンディションも存在します。詳細を知るにはこちらの情報をチェックしてください。
その他の脆弱性
Webソケットはサーバーサイドとクライアントサイドにデータを送信するメカニズムであるため、サーバーとクライアントが情報を処理する方法によっては、Webソケットを使用してXSS、SQLi、または他の一般的なWeb脆弱性を悪用することができます。
WebSocket Smuggling
この脆弱性により、逆プロキシの制限をバイパスして、逆プロキシがWebSocket通信が確立されたと信じるようにすることができます(実際にはそうではない場合もあります)。これにより、攻撃者は隠されたエンドポイントにアクセスすることができます。詳細については、以下のページをご覧ください:
参考文献
Last updated