WebSocketの闇：リアルタイム通信のリスク
はじめに
WebSocketは単一のTCP接続でフルデュプレックスのデータ通信を行うことができる通信プロトコルで、双方向のシームレスな通信を促進します。昨今、ウェブアプリケーションではリアルタイムインタラクションに対するニーズが高まっているためWebSocketが広く導入されるようになりました。その結果、インスタントメッセージング、ライブ通知、オンラインゲーム、インタラクティブなダッシュボードにも利用されています。ただしこのような利用増により攻撃サーフェスも拡大しており、アプリケーションが重大なセキュリティ脆弱性にさらされています。
このブログではWebSocketプロトコルの脆弱性について説明します。WebSocketの基本的な知識から始まり、その仕組み、必要性、具体的な脆弱性とその影響について述べます。脆弱性検出の自動化、スキャニング機能の強化、全体的なセキュリティ体制の改善にAIがどのように役立つのかについても説明します。
WebSocketについて：その概要、理由、使用法
WebSocketとは？
WebSocketはウェブブラウザとサーバー間で継続的に双方向の通信を行えるようにする標準プロトコルです。リクエスト-レスポンスメカニズムに依存しているHTTPとは異なり、WebSocketは永続的な接続を確立し、接続を繰り返し開閉しなくても双方向にデータを同時に流すことができるため、従来のHTTPよりもレイテンシが非常に少なくなります。
WebSocketを使用する理由
WebSocketはリアルタイムアプリケーションに最適です。従来のHTTPポーリング方法には大量のリソースが必要なためレイテンシが発生します。WebSocketはオープンコネクションを維持することでこの問題を解決し、チャットルーム、ライブストリーミング、オンラインゲーム、共同編集、インタラクティブなウェブアプリなどのアプリケーションに適したものになっています。
WebSocketの仕組み
WebSocketプロトコルは以下の2つの段階を経て機能します。
- ハンドシェイク：HTTPアップグレードリクエストで接続を開始し、通信プロトコルがHTTPからWebSocketに変化します。
- 通信：アップグレード後、サーバーとクライアントがフレーム内の永続的な接続でデータを交換することで、効率的かつリアルタイムのメッセージ送信が行えます。
ハンドシェイクの段階と継続的なフレームベースの通信は効率的ですが、攻撃者にエクスプロイトされる可能性があるセキュリティリスクがあります。
一般的なWebSocketの脆弱性
このセクションではWebSocketの実装に影響があるいくつかの主な脆弱性について、実際のシナリオ、例、報告されているCVEと共に紹介します。
1. WebSocketによる認証バイパス
WebSocketの実証でユーザーの認証が正しく行えなかった場合、またはセッション状態を安全に維持できない場合に、認証バイパスの脆弱性が発生します。この脆弱性をエクスプロイトすることで攻撃者は不正にアクセスできるようになり、機密データが漏えいしてしまう可能性があります。
2.インジェクション攻撃（SQL、コマンド、XSSなど）
ユーザー入力を伴う他の通信方法と同様に、ユーザー入力が十分にサニタイズされていない場合、WebSocketsはインジェクション攻撃に遭う可能性があります。攻撃者はWebSocketメッセージによって悪意のあるコードやコマンドを挿入することで、SQLインジェクション、コマンド実行、またはXSS（Cross-Site Scripting）を生じさせることができます。
3.クロスサイトWebSocketハイジャッキング（CSWH）
クロスサイトWebSocketハイジャッキングは、攻撃者がユーザーのブラウザをだまして、既存の認証済みセッションを使って不正なWebSocket接続を確立することで発生します。これにより攻撃者は不正にメッセージの傍受、改ざん、送信を行うことができます。
WebSocketを使用した現実の攻撃シナリオ
WebSocketインジェクションによる不正なリアルタイムデータアクセス
WebSocketの一般的な用途の1つがリアルタイム通知です。典型的なシナリオでは、websocketのハンドシェイクフェーズを終えると、サーバーがユーザーIDとプロジェクトIDの両方を期待します。この設計では特定のプロジェクトに関連するユーザーにのみ通知が送信されるようになっています。
たとえば通常のwebsocketリクエストでは、新しいファイルがアップロードされると対応する通知が送信されます。
ただし私達の調査では、特定のユーザーIDとプロジェクトIDの代わりにアスタリスク（*）などのワイルドカード文字を送信することで、websocketがあらゆるユーザーとプロジェクトに通知を送信し始め、ユーザーの機密情報やプロジェクトファイルへの不正アクセスが可能な状態になってしまうことが判明しました。
これにより保護が必要な膨大な量のリアルタイムデータが公開されてしまい、ウェブサイトでのwebsocket通信のアクセスコントロールにおける重大な問題点が明らかになりました。
WebSocketからの通知操作
ログインページのあるウェブサイトではページを読み込むとすぐにwebsocket接続がバックグラウンドで確立され、関連するデータベースでの新たな変更に関する情報を取得します。たとえば以下のリクエストとレスポンスを見てみましょう。
サーバーに送信されたメッセージを分析すると、少なくともリクエストを改ざんしてバイナリコンテキストの代わりに解読可能な情報を入手することは比較的容易なようです。ただし調査では驚くべき発見がありました。リクエストにいくつかの簡単な変更を加えるだけで、受信したデータにアプリケーション内での最近の変更が含まれるだけでなく、ユーザークレデンシャルのエクスポージャも可能になりました。
CVE-2024-55591 / CVE-2025-24472
FortiOSとFortiProxyでの認証バイパスはNode.js websocketモジュールでの不適切な処理に起因しています。具体的には不正に作成したリクエストで代替認証パスのエクスプロイトを行い、リモート攻撃者がsuper-adminに権限をエスカレーションできるようにします。この脆弱性によってWebSocketのセキュアな実装と厳格な入力検証により、制限されたコンテンツへの不正なアクセスを防止することが非常に重要だということを再確認することができます。
使用事例に関する結論
WebSocketはチャットアプリケーション、通知、その他のリアルタイムデータ通信関連のシナリオでの使用が一般的ですが、間違った実装に起因するセキュリティ上および機密上のリスクを開発者は軽視しがちです。これにより意図していなかった用途に拡大され、システムがより広範な脅威にさらされる場合があります。
チャットボットや簡単な通知など、一見すると無害な用途であっても、脆弱性を見逃した場合、それがエクスプロイトされ、大きな被害が発生することがあります。そのため、すべてのWebSocketの実装に対して厳格なセキュリティを講じることが不可欠です。
WebSocket通信のセキュリティ確保：ベストプラクティス
- 入力の検証：受信するすべてのWebSocketメッセージが厳格に検証、サニタイズされていることを確認します。入力を適切に検証することで悪意のある、または不正な形式のデータを処理前にブロックできるので、インジェクション攻撃や予期しない挙動のリスクが大幅に低減できます。
- チケットベースの認証：チケットベースの認証など、堅牢な認証メカニズムを実装することでWebSocketのハンドシェイク中にユーザーを効果的に検証できます。これによりセッションを安全に確立して不正なアクセスのリスクを最小化できます。
- WebSocket Secure (wss://)：インセキュアなws:// 接続ではなく常にセキュアなWebSocket接続（wss://）を使用します。TLS暗号化を使用することでデータ傍受を防止し、クライアントとサーバー間で暗号化されたセキュアな通信が確保できます。
- Originヘッダーの確認：WebSocketのハンドシェイク中にOriginヘッダーを厳格に検証します。Originを適切に確認することで信頼できるドメインからの接続であることを確かめ、クロスサイトWebSocketハイジャック（CSWSH）を回避することができます。
AIを使用してWebSocketの脆弱性を自動的に検出
WebSocketの脆弱性に効果的に対処するため、ULTRA REDはAIを使った技法をセキュリティスキャニングプロセスに統合しました。ルールベースの厳格な方法とは異なり、弊社のAIシステムはマシンラーニングと自然言語処理を使用して複雑なロジックの問題点、認証バイパス、WebSocketトラフィック内に仕掛けられたインジェクション攻撃を検出することができます。
継続的な改善により、ULTRA RED CTEMプラットフォームはより迅速に脆弱性を検出できるようになりました。またアラームの誤発出も軽減し、従来の方法では見過ごされることが多かった脅威も捕捉することができます。推測しながらの手作業よりもスマートなツールで作業するほうが明らかに効率的だからです。
