WebSocketセキュリティ

WebSocketの概要 

WebSocket規格は、クライアントとサーバの間で双方向（フルデュプレックス）の通信を大幅に効率化できるため、注目が高まっています。 

これを実現するため、WebSocketはOSI参照モデルの第7層（アプリ層）を活用しています。これにより、チャットや写真共有など、変化するリアルタイムなウェブアプリの発展が促進されます。

WebSocketは、従来のブラウザとサーバ間の通信で以下の制限を回避します：

• 従来、ホストは常時待機してクライアントの問い合わせに応答していましたが、クライアント側（ブラウザ利用者）で継続的な接続を維持する仕組みはなく、すべての通信がクライアントからのリクエストとサーバの応答に依存していました。
• 通信はクライアント依存であり、リソースは利用者の要求に応じてサーバから配布されます。
• 利用者はしばしばサーバの結果を再読み込みする必要があり、これが常時監視となります。そのため、ツールは同時応答を簡略化し、どのように応答するかを判断する必要があり、コールバック方式が一般的に採用されています。  

WebSocketプロトコルの詳細

このプロトコルは、明確にフルデュプレックス通信を定義しています。WebSocketにより、ウェブブラウザが強力なデスクトップ機能を利用できるようになり、長らく期待されていたクライアント／サーバのウェブプログラミングの進化を象徴します。

以下は、WebSocketの主な特徴です：

• WebSocketプロトコルは標準化が進み、ウェブサーバと利用者間の即時通信が可能となっています。
• クロスプラットフォームの通信規格として、WebSocketは利用者とサーバ間の即時通信で人気が高まっています。
• この仕組みにより新たなアプリが実現可能となり、リアルタイムで動作するウェブアプリの企業成長が促進されます。
• WebSocketを守る最大の利点は、単一のTCP接続上で相互（フルデュプレックス）通信が可能になる点です。

‍

WebSocketが脆弱な攻撃とは？

最も一般的なWebSocketの欠陥とその悪用方法を見ていきます：

1. 認証/認可

WebSocket規格では、利用者の認証や許可に関する規定が含まれていません。特に機微なデータを扱う場合、ソフトウェア側で対応する必要があります。

2. DoS攻撃

WebSocketを用いると、サーバは無限の応答を受け入れてしまう場合があります。これを悪用し、悪意あるハッカーがDoS攻撃でサーバに過負荷をかけ、資源を枯渇させることにより、ウェブページの表示が非常に遅くなります。

3. トンネリング

WebSocketを利用すると、誰でも任意のTCPアプリを通じてデータを送ることが可能です。例えば、トンネリングにより、ウェブブラウザから即時に暗号化された接続が主要なデータベースへ確立されると、クロスサイトスクリプティング攻撃が本格的なフィッシング詐欺に発展する恐れがあります。

4. スニッフィング攻撃

ハイパーテキスト転送プロトコルと同様、WebSocket規格でもデータがやり取りされるため、中間者攻撃によりデータが悪用される恐れがあります。データ漏洩を防ぐには、WebSocket Secure (wss://)方式を用いてください。wssはトランスポート層セキュリティを利用して情報を守りますが、ウェブアプリがHTTPSと同等の保護を受けるわけではありません。

5. データマスキング

データを隠す行為自体は必ずしも悪いことではありません。WebSocketの技術では、汚染されたブラウザキャッシュといった問題を回避するために利用されることがあります。しかし、データマスキングは通信パターンを覆い隠し、監視プログラムがそれを検出しにくくする問題もあります。 

データ損失防止（DLP）技術はWebSocketを対象にしていないため、WebSocketの通信量を適切に評価できず、不正なJavaScriptや情報漏洩の検出が難しくなります。

6. 入力データ攻撃への脆弱性

認証されていない入力専用攻撃が脆弱性を狙った場合、何が起こるでしょうか。代表的でありながら、オンライン上の可視性に大きな影響を及ぼすのがクロスサイトスクリプティングです。 

7. ハンドシェイク時の認証が行われない

WebSocketプロトコルでは、ハンドシェイク中にネットワーク接続が利用者の認証を行うことはできません。通常のHTTP通信手段のみが利用可能で、クッキー、HTTPプロトコル、TLS認証などが使われますが、HTTPとWSはこの仕組みにより円滑に通信できます。

このため、HTTPがWSへ直接検証データを送信でき、不正なクロスサイトWebSocketハイジャック攻撃につながる恐れがあります。

8. 暗号化されていないTCPチャネル

WebSocketは、より高いセキュリティが求められるTCP経路上で利用できるため、様々な問題が生じます。多くの問題は、OWASP A3で指摘される機微なデータの露出として挙げられています。

WebSocketのセキュリティ向上のためのヒント

WebSocketをどのように守るか？ 以下が主要なヒントです：  

WSS

安全でないws://より、wss://の利用を選ぶべきです。WSS（SSL/TLS上のWebSocket）はHTTPSと同様に守られ、中間者攻撃を防ぎます。通信が守られていれば、WebSocketへの多重攻撃は困難となります。

クライアント側の入力検証

WebSocketリンクは、ブラウザに関係なく容易に構築できるため、不正な情報がやり取りされる可能性があります。クライアントからのデータと同様、必ず十分に検証してから処理してください。HTTPもWebSocketも、SQLインジェクションの脅威にさらされます。

サーバ側のデータ検証

サーバから返されるデータも同様に注意深く扱う必要があります。クライアントからの通信は常にデータとして処理し、DOMへ直接代入したりコードとして評価することは避け、結果がJSONの場合はJSON.parse()を使用して安全に読み取ってください。

チケットベースの認証

WebSocket（WS）のインターフェースは認証も許可も自動で扱いません。そのため、認証が必要なサイトからWSを開始する場合、通信を守る対策が求められます。

WSは通常のHTTPヘッダーを通じて認証情報を渡すため、様々な対策が可能です。ウェブビューと同じセキュリティ手法をWS通信にも適用してください。

そのため、チケットベースの認証方式はWSのセキュリティ課題に効果的な対策の一つと考えられます。一般的な流れは以下のとおりです：

• WS接続を開始する際、クライアント側のプログラムがHTTPリクエストを扱うウェブサーバに対して、認証用の「チケット」を要求します。
• サーバ管理者がこのチケットを発行します。通常、チケットには利用者のIPアドレス、日時、その他必要な内部記録が含まれます。

トンネリングの回避

WebSocketを利用すると、任意のTCPアプリが簡単にトンネリングされる恐れがあります。例えば、データベースからブラウザへの接続をトンネリングすると、不正なクロスサイトスクリプティング攻撃により、ブラウザ内の攻撃者がリソースにアクセスし、XSS攻撃が大規模な侵入へと発展する危険性があります。可能な限りトンネリングは避け、より堅牢かつ十分に検証されたWebSocketベースのインターフェースを構築してください。

レート制限

レート制限は、ウェブサービスやアプリの不正利用を防ぐための重要な対策です。不正な自動システムやスクレイピング攻撃、または壊れたクライアントによる偶発的なDoS攻撃から守ります。

各利用者に「バケット」を設け、次の項目を基にレート制限を設定してください：

• 1秒あたり、利用者が送信するWebSocketトラフィック量
• サーバが安全に処理できる1秒あたりのトラフィック量 
• サーバの帯域幅を超える同一利用者からのデータは、キューに入れる
• 利用者の使用量が一時的に急増し、その後待機リストを処理できる静止期間を考慮して、特定のタイムアウト時間を設定する
• タイムアウト後、待機中の項目は拒否する  

オリジンヘッダー

WebSocketプロトコルでは、リクエスト発信元のURLがOriginフィールドに記載されます。これにより、異なるドメインから開始されたWebSocket接続や、ブラウザと他のクライアントとの区別が可能ですが、Originヘッダーはあくまで参考情報であり、ブラウザ以外のクライアントが任意の値を設定可能なため、信頼性は低い点に注意してください。

Origin要素は、AJAXリクエストで用いられるX-Requested-Withヘッダーに似ています。ウェブブラウザは、直接行われたAJAXリクエストとアプリが生成したリクエストとを区別するためにX-Requested-With: XMLHttpRequestを送信しますが、ブラウザ以外のクライアントは容易にこのヘッダーを変更できるため、検証の指標としては不十分です。

WallarmでのAPIセキュリティ

Wallarmは優れたAPIセキュリティ評価ツールで、アプリのAPIやWebSocketをスキャンし、欠陥を検出します。WebSocketの不具合修正に有効です。

このプラットフォームは自動解析機能を備え、ウェブアプリ/APIのセキュリティ上の弱点を特定します。迅速に欠陥を発見し、プログラマーへ修正の手引きを提供するか、脆弱性監視システム内でバグレポートを作成するなど、WebSocketのセキュリティ問題への対策として有用です。