WebSocketフレームのマスクは何ですか？

Question

私はwebsocketの実装に取り​​組んでおり、フレーム内のマスクの意味が分かりません。

誰かがそれが何をしているのか、なぜそれが推奨されるのかを説明できますか？

0     1     2     3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-------+-+-------------+-------------------------------+ 
|F|R|R|R| opcode|M| Payload len | Extended payload length | 
|I|S|S|S| (4) |A|  (7)  |    (16/64)   | 
|N|V|V|V|  |S|    | (if payload len==126/127) | 
| |1|2|3|  |K|    |        | 
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + 
|  Extended payload length continued, if payload len == 127 | 
+ - - - - - - - - - - - - - - - +-------------------------------+ 
|        |Masking-key, if MASK set to 1 | 
+-------------------------------+-------------------------------+ 
| Masking-key (continued)  |   Payload Data   | 
+-------------------------------- - - - - - - - - - - - - - - - + 
:      Payload Data continued ...    : 
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 
|      Payload Data continued ...    | 
+---------------------------------------------------------------+ 

Answer 1

WebSocketををSection 5.3に述べRFC6455で定義されています。

マスキングキーの予測不可能性は、ワイヤ上に表示され バイトを選択するから悪質なアプリケーションの作成者を防ぐために 不可欠です。

マスキングキー（32ビット）：マスクビットがセットされていれば（そして私を信頼し、サーバー側のために書くならば、それは）私は以下の説明を見つけたblog entry about Websocketsで

ペイロードのxorに使用される符号なしバイトをここで読み取ることができます。 これは、クライアント側の攻撃者が不正なプロキシを悪用できないようにするために使用されます。

しかし、私がmailing list archiveで見つけた最も明確な答え。ジョンTamplinがあり状態：

基本的に

、WebSocketをその中にユニークであるあなたが悪意のあるコードのクライアントで実行して、サーバーの完全な 敵対的な制御、およびだけで作品を持っている場合でも、ネットワーク インフラを保護する必要があります信頼できるクライアントブラウザは です。 ブラウザが各 フレームに対してランダムマスクを生成するようにすることで、敵対的なクライアントコードは、 と表示されたバイトパターンを選択して、脆弱なネットワークインフラストラクチャを攻撃することはできません。

kmkaplanが述べているように、攻撃ベクトルはRFCのSection 10.3に記載されています。
これは、プロキシキャッシュポイズニング攻撃を防止する手段です（Paper about the attackを参照）。 それは何らかのランダム性を作り出しています。ペイロードとランダムなマスキング・キーをXORする必要があります。

ところで：それだけではお勧めしません。 、義務的なです。 this articleから

Answer 2

：クライアントからサーバへのトラフィックが原因で、悪意のあるコードが間違ったことをして、いくつかの種類の攻撃としてこれを使用するために、いくつかの壊れたプロキシを引き起こす可能性は低いチャンスが要求される

マスキングのWebSocketの

。これは実際に起こる可能性があるとは誰も証明していませんが、ブラウザベンダーが悩むほど十分な理由だったので、マスキングを追加して攻撃として使用する可能性を排除しました。

したがって、マスキングが特別な方法で細工され、これらの2つのエンドポイント間で送信されるバイトのシーケンスを防止するように設計され、攻撃者がブラウザで実行されるJavaScriptコードだけでなく、バ​​ックエンド・サーバーの両方を妥協することができたと仮定するとこれらの2つのエンドポイント間の壊れたプロキシを混乱させる可能性があります（これは、Websocketストリームを実際にはHTTPとして解釈しないプロキシを意味します）。

ブラウザ（ブラウザのJavaScriptコードではありません）は、メッセージを送信するために使用されたランダムに生成されたマスクについて最終的な発言をしています。なぜなら、攻撃者は、されます。

WebSocketストリームが暗号化されている場合は、マスクが冗長であることに注意してください。 Article Python Flaskの作者から：

なぜマスキングがありますか？明らかに、そこにそこに十分な壊れたインフラストラクチャがあるので、アップグレードのヘッダーを通過させ、その後、接続の残りの部分を2番目のHTTP要求として処理してから、キャッシュに入れます。私はこれについて言葉を持っていません。いずれにせよ、それに対する防御は、基本的にはマスキングキーとしての強力な32ビット乱数です。それとも... TLSを使って、ちっちゃなプロキシを使わないでください。