第9章 1.WebSocket

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

WebSocket とは

WebSocket はブラウザと Webサーバの間の双方向通信の規格であり、RFC 6455, "The WebSocket Protocol"（注釈）として規定されている。この規格はヘッダーによるオーバーヘッドが少なく、高効率な伝送を実現している。「リアルタイムWeb」を実現する技術として注目されている。

1. 注釈：
   RFC 6455, "The WebSocket Protocol"

脅威シナリオ

WebSocketについての「脅威シナリオ」を、3つ掲げる。

ケース1： 信頼できないwebSocketへの接続

ブラウザ上のWebコンテンツに入り込んだ悪意のスクリプトが、悪意のサーバとの間をWebSocketで接続し、悪意のサーバがクライアントマシンを攻撃するケースである。

このケースのシナリオは次のようなものである。

1. スクリプト注入攻撃によって、悪意のスクリプトがブラウザへ侵入する
2. このスクリプトが、攻撃者のサーバへ勝手にWebSocket接続する
3. WebSocketを通じて、さらなるマルウェアがダウンロードされたり、クライアントPCが攻撃者のサーバから遠隔操作される

WebSocketは、ブラウザ・サーバ間の双方向の通信路を確保してくれる。これはサーバ側で標的を待ち構えている攻撃者にとっても好都合である。クライアントPCの不正な遠隔操作が以前より行いやすくなったためである。

このケースは、スクリプト注入（いわゆるXSS）による被害の広がりが、さらに大きなものになりうることを示している。

ケース2： ブラウザからサーバへの攻撃

WebSocketサーバが信頼しているサイト群を源泉とするWebコンテンツの中に入り込んだ悪意のスクリプトが善意のWebソケットサーバを侵害するケースである。

このケースのシナリオは次のようなものである。

1. スクリプト注入攻撃によって、悪意のスクリプトがブラウザへ侵入する
2. このスクリプトが、善意のサーバへ勝手にWebSocket接続する
3. WebSocketを通じて、スクリプトが善意のサーバを攻撃する

もしWebSocketサーバが、「Origin:」リクエストヘッダの値のみを見てクライアント側を信頼するよう作られている場合、スクリプト注入で侵入したスクリプトもこのWebSocketサーバに電文を投げ、サーバ側を不正に操作したり、サービスを不正に受けることができる。

このケースも、スクリプト注入（いわゆるXSS）による被害の広がりが大きなものになり得ることを示している。

ケース3：非ブラウザからサーバへの攻撃

非ブラウザのクライアントソフトウェアが善意のWebソケットサーバを侵害するケースである。

このケースのシナリオは次のようなものである。

1. WebSocketに対するブラウザの動きをそっくりまねたクライアントソフトウェアを作ることができる
2. このアプリケーションが、善意のサーバへ勝手にWebSocket接続する
3. WebSocketを通じて、このアプリケーションが善意のサーバへの攻撃を行う

このケースが厄介なのは、サーバ側が 「Origin:」 リクエストヘッダを検査して、特定の源泉のコンテンツからの WebSocket 接続要求のみを受け付けるつもりでいても、第三者は自由に WebSocket 接続が行えるところである。

ケース2 と ケース3 に共通する論点

論点1： ユーザ認証・アクセス認可の欠如

WebSocketの内部の通信は、標準ではユーザ認証・アクセス認可の仕組みを備えていない。

WebSocketを通じてサーバへ投入される「コマンド」に関して何も手段が講じられていないと、ひとたび悪意のクライアントが接続に成功すれば、不当なサーバ操作コマンドが投入され実行される。

サーバ側プログラムにおいては、扱う情報の重要度に見合ったユーザ認証・アクセス認可の仕組み構築する必要がある。

論点2： 「Origin:」リクエストヘッダのチェック

ケース2 と ケース3 は、サーバ側が「Origin:」リクエストヘッダを慎重に検査していたとしても生じる侵害である。これらにおいて、「Origin:」リクエストヘッダの検査は役に立たない。本来の源泉は違うにもかかわらず、悪意のスクリプトやプログラムは正規の「Origin:」リクエストヘッダをサーバへ送信することができるからである。

とはいえ「Origin:」リクエストヘッダの妥当性の検証を省略すべきではない。別の源泉
のコンテンツから接続を試みるといった単純な試みを排除できる。

論点3： 第三者による通信の傍受と改ざん

WebSocketのプロトコルのスキームには、「ws:」と「wss:」のふたつがある。「ws:」においては平文で通信が行われ、「wss:」においてはTLS（以前のSSL）を用いた暗号通信が行われる。

WebSocket中を通す情報が他者に傍受・干渉されては困るものである場合は、「wss:」を使う必要がある。

参考資料

• OWASP "HTML5 Security Cheat Sheet"
• WebSockets