Websocket を開くために、クライアントはサーバー上の tcp ソケットに接続し、ハンドシェイクを開始します。
クライアントのハンドシェイクには、base64 でエンコードされたキー (Sec-WebScoket-Key) が含まれています。
サーバーは、base64 でエンコードされた SHA-1(key + magic_constant) で応答することになっています。magic_constant は、プロトコル固有の文字列 (Sec-Websocket-Accept) です。
これの目的は何ですか？そうする明らかなセキュリティ上の理由は見当たりません。どちらの当事者も認証しません。単一の SHA-1 計算は、作業証明にはあまり適していません。
ハンドシェイクのこの部分の目的は、接続の両側が本物の WebSocket 参加者であることを確認することです。これは、実際の WebSocket クライアントおよびサーバーに簡単に実装できるように設計されていますが、攻撃者が HTTP クライアント、サーバー、またはプロキシをだまして WebSocket 参加者のふりをさせるのは困難です。特に、ブラウザーで実行されている悪意のある JavaScript の一部が通常の HTTP サーバーへの WebSocket 接続を開くことができれば、まずいでしょう。接続が確立されると、JavaScript はチャネルを介して送信される内容を完全に制御し、試行できるからです。サーバーを侵害または停止しようとする、あらゆる種類の異常な形式の過大なデータ。
更新：
@notallama が指摘しているように、悪意のある WebSocket クライアントを作成したり、単に telnet を使用して悪意のあるデータを送信したりするのは簡単です。違いは、WebSocket では、攻撃が信頼できるコンテキスト (ユーザーのブラウザーとユーザーのネットワーク) から発生することです。ブラウザーはインターネットから信頼できないコードを読み込みますが、インターネット全体に公開されていない HTTP サーバーや仲介者に接続するためによく使用されます。極端な例として、WebSocket の代わりに、ブラウザーが生の TCP 接続を開くことができたとします (CORS の強制やハッシュ チェックなどはありません)。現在、JavaScript の悪意のある部分は、ユーザーのホーム ネットワーク (さらに悪いことに、職場のイントラネット) で必要なことを何でも行うことができます。
特に、HyBi ワーキング グループは、WebSocket 接続を使用して仲介者をだまして、通常の HTTP クライアントと通信していると思わせることで、HTTP 仲介者の理論上の脆弱性に対処するために多大な時間を費やしました。