WebSocket-セキュリティ

プロトコルはセキュリティ上の理由から設計する必要があります。WebSocketはまったく新しいプロトコルであり、すべてのWebブラウザーが正しく実装しているわけではありません。たとえば、仕様では逆のことを暗示していますが、HTTPとWSの組み合わせを許可しているものもあります。この章では、ユーザーが知っておくべきいくつかの一般的なセキュリティ攻撃について説明します。

サービス拒否

サービス拒否（DoS）攻撃は、マシンまたはネットワークリソースを、それを要求するユーザーが利用できないようにしようとします。誰かがWebサーバーに対して、時間間隔がないか、わずかな時間間隔で無限の数の要求を行ったとします。サーバーは各接続を処理できず、応答を停止するか、応答が遅すぎます。これは、サービス拒否攻撃と呼ぶことができます。

サービス拒否は、Webページをロードすることさえできなかったエンドユーザーにとって非常に苛立たしいものです。

DoS攻撃はピアツーピア通信にも適用される可能性があり、P2Pネットワークのクライアントに被害者のWebサーバーへの同時接続を強制します。

真ん中の男

例を使ってこれを理解しましょう。

人を想定します A 彼の友人とチャットしています BIMクライアント経由。第三者があなたが交換したメッセージを見たいと思っています。それで、彼は両方の人と独立したつながりを作ります。彼はまた人にメッセージを送りますA と彼の友人 B、あなたのコミュニケーションの目に見えない中間体として。これは、man-in-the-middle攻撃として知られています。

侵入者はパッケージを直接読み取ることができるため、中間者攻撃は暗号化されていない接続の方が簡単です。接続が暗号化されている場合、攻撃者は情報を復号化する必要がありますが、これは非常に難しい場合があります。

技術的な観点から、攻撃者は公開鍵メッセージ交換を傍受し、要求された鍵を自分の鍵に置き換えながらメッセージを送信します。明らかに、攻撃者の仕事を困難にするための確実な戦略は、WebSocketでSSHを使用することです。

ほとんどの場合、重要なデータを交換するときは、暗号化されていないWSではなくWSSの安全な接続を優先します。

XSS

クロスサイトスクリプティング（XSS）は、攻撃者がクライアント側のスクリプトをWebページまたはアプリケーションに挿入できるようにする脆弱性です。攻撃者は、アプリケーションハブを使用してHTMLまたはJavascriptコードを送信し、このコードをクライアントのマシンで実行させることができます。

WebSocketのネイティブ防御メカニズム

デフォルトでは、WebSocketプロトコルは安全になるように設計されています。現実の世界では、ブラウザの実装が不十分なために発生する可能性のあるさまざまな問題がユーザーに発生する可能性があります。時間が経つにつれて、ブラウザベンダーは問題をすぐに修正します。

SSH（またはTLS）を介した安全なWebSocket接続が使用されている場合、セキュリティの追加レイヤーが追加されます。

WebSocketの世界では、主な関心事は安全な接続のパフォーマンスです。上部にはまだ追加のTLSレイヤーがありますが、プロトコル自体にはこの種の使用のための最適化が含まれており、さらにWSSはプロキシを介してよりスムーズに機能します。

クライアントからサーバーへのマスキング

WebSocketサーバーとWebSocketクライアント間で送信されるすべてのメッセージには、マスキングキーという名前の特定のキーが含まれています。これにより、WebSocket準拠の仲介者はメッセージのマスクを解除して検査できます。仲介者がWebSocketに準拠していない場合、メッセージは影響を受けません。WebSocketプロトコルを実装するブラウザーは、マスキングを処理します。

セキュリティツールボックス

最後に、WebSocketクライアントとサーバー間の情報の流れを調査し、交換されたデータを分析し、考えられるリスクを特定するための便利なツールを紹介できます。

ブラウザ開発ツール

Chrome、Firefox、Operaは、開発者サポートの点で優れたブラウザです。彼らの組み込みツールは、クライアント側の相互作用とリソースのほぼすべての側面を決定するのに役立ちます。これは、セキュリティの目的で大きな役割を果たします。