透過プロキシの脆弱性、WebSocket葬儀のキャンセル、呼気...
「Web Sockets Temporarily Canceled」を読んだ後、私は抵抗することができず、応答することにしました。
だから、ITの前線からの最新ニュース。 彼らは衝撃的です。
Adobe Flashには深刻なオープン脆弱性があるため、すべての主要なブラウザーがサポートを拒否しました。 はい、はい、ネットワーク上にフラッシュはもう存在しません。 これは私の庭のベンチに座っているすべての主要な祖母によって述べられました。
9までのすべてのバージョンのInternet Explorerに深刻なオープン脆弱性があるため、すべてのIEユーザーはネットワークへのアクセスを拒否します。 レイアウトデザイナーにとっての新しい悪夢-IEのさまざまなバージョンのサイトバージョンを維持する必要がなくなりました。 悪夢！ 取得したスキルをどうするか？ 管理人の空きスペースはどこですか？
Windowsの深刻なオープン脆弱性のため、すべてのブラウザーメーカーはこのプラットフォームのサポートを拒否しています。 「はい、はい、ReactOSに切り替えています」と、大手市場の大手企業の主要ブラウザの主要開発者が独占インタビューで確認しました。
最後に、Industrialでの冬用タイヤの開発責任者の発表は、神格化でした。 「タイヤを取り付けた車で発生した1829783の事故を分析しました。 そして、彼ら全員が丸い車輪を持っているという結論に達しました。 運転の安全性が私たちのすべてなので、丸い車輪を捨てて四角い車輪に進むことにしました。 „
冗談を言って、それで十分です。 それを理解してみましょう。
まず第一に、Adam Barthの記事は「透明なプロキシ：脅威か脅威か？」というタイトルでした。 つまり、作成者はWebSocketプロトコルではなく、「透過的なプロキシ」を調べます。
これは何ですか 簡単です-クライアントがプロキシを明示的に指定した場合、これは明示的なプロキシです。 また、ブラウザのリクエスト（ホテルなど）が、フィルタリング用の特別なプロキシによって感知されないように傍受された場合、これは「透過的な」プロキシになります。
問題（著者による）は次のとおりです。 透過プロキシがHTTP要求を受信しました。 プロキシは透過的であるため、クライアントから特定のIPアドレス（サーバー）に送信された要求をインターセプトします。 同時に、HTTP要求自体でホスト要求を指定することもできます。 ロジックの観点から、プロキシはリクエストを送信先、つまり送信元IPに送信する必要があるようです。 ただし、著者によると、一部のプロキシは、ホストリクエストヘッダー内のホストに対応するIPアドレスにHTTPリクエストを送信します。
「正しさ」の観点からこの決定については説明しません。 一部の透過プロキシが、Hostヘッダー内のホストにリクエストをリダイレクトするとします。 これから何が続きますか？
作者はさらに別のドキュメントについて言及します 。
悪意のあるサイトが、生のソケットを使用する許可を受けたブラウザーにFlashアプリケーションをダウンロードした、つまり、単純に言えば、Flashアプリケーションはダウンロード元のサーバーへのTCP / IP接続を使用できると仮定します。 透過プロキシは、そのような接続をブラウザから区別できますか？ できません。 Flashアプリケーションが正しいHTTPリクエストを生成し、TCP経由でサーバーに送信すると、透過プロキシはブラウザがこのリクエストを送信することを決定します。 悪意のあるフラッシュアプリケーションは、悪意のあるホストを指す悪意のあるリクエストにHostを挿入します。
そして今、プロキシがホストフィールドで（悪意のある）ホストへの応答を受信するほど愚かである場合、このサーバーから何かがスリップされ、プロキシは元の（良い）ホスト（IPアドレスが最初にリクエストを送信しました）。
次の2つの問題があります。
1.悪意のあるフラッシュアプリケーションは、ダウンロード元のWebサーバーだけでなく、どのWebサーバーにもアクセスできるようになりました。
2.プロキシが応答をキャッシュする場合、クライアントから正常なサーバーへの後続の要求は、悪意のあるキャッシュされた応答を受け取ります。
そのため、 透過プロキシがホストヘッダー内のホストにリクエストをリダイレクトする場合（リクエストが送信されたIPアドレスを使用する代わりに）、透過プロキシキャッシュを侵害してSOPフラッシュアプリケーションを破壊する問題が発生します。
また、Luzhkov WebSocketはどこにありますか？ それとは何の関係もありません。 どうぞ 若い RFC マーモットの百科事典を見てください。 透明なプロキシを定義するRFC 1919に興味があります。 私たちは読みます：
つまり、標準では、ホストフィールドからではなく、リクエストのIPアドレスを取得する必要があると明確に述べています 。
繰り返しますが、WebSocketのせいではないようです。 さて、著者による元の記事に戻ります。
著者は実験を行った。 彼らは、同様のスキーム、つまり「異なる」ホストでHTTPリクエストを送信しようとする広告バナーを人々に配りました。 フラッシュアプリケーションとJavaアプリケーションの両方が使用されました。 実験では、「悪意のある」Flashを使用するリクエストの2.2％（36305の803）および「悪意のある」Javaクラスを使用するリクエストの3.6％（33820の1212）が、IPアドレスではなくHTTPヘッダーのホストにリダイレクトされました。
さらに、作成者はWebSocketプロトコルを使用してプロキシを「だます」ことを試みます。 透過プロキシがWebSocketについて何も知らない場合、クライアントは次の形式のメッセージをWebSocketハンドシェイクに送信できます。
不幸なプロキシはWebSocketについて何も知らないため、これは別のHTTPリクエストであると判断します。 そして、彼はvictim.comに「行き」、そこに転送します。 著者の実験は、プロキシの2.8％がこれを行ったことを示しました（49218のうち1376）。 さらに、実験は本質的に繰り返されました。
したがって、WebSocketが安全でないという主張は誤りです。
透明なプロキシがWebSocketを知らず、RFC 1919に違反するため、セキュリティ違反が発生します 。
この調査の著者は、WebSocketにHTTP CONNECTコマンドを使用するというソリューションを提供しています。 彼らの実験は、_all_透過プロキシがCONNECTをうまく機能させることを示しました。 彼らは内部にHTTPSデータがあると信じており、それを解析しようとはしません。 要求はソースIPに送信されます。
まとめると。
透過プロキシの約3％が、HTTPリクエストをリクエストヘッダーのHostフィールドで指定されたホストIPアドレスにルートします。 これは、RFC 1919標準の違反であり、ルートは、要求が送信された送信元IPアドレスで実行する必要があります。
この動作により、悪意のあるFlashアプリケーション、Javaアプレット、またはJavaScriptが任意のサイトにアクセスし（同一生成元ポリシーの違反）、これらのプロキシのキャッシュを侵害することができます。
悪意のあるJavaScriptスクリプトは、ブラウザがWebSocketをサポートしている場合にのみ害を及ぼす可能性があります。 FlashアプリケーションとJavaアプレットは、WebSocketブラウザーのサポートを必要としません。
ハンドシェイクWebSocketでCONNECTコマンドに切り替えると（いくつか改善されています）、WebSocketの場合に「穴を閉じる」ことができます...
...ただし、SOPを破り、プロキシキャッシュがRCF 1919を破るまでプロキシキャッシュステイをコメントするために、悪意のあるフラッシュとJavaアプリケーションを使用します。
気晴らしのための画像。
PS
追加するのを忘れました。 OperaおよびFireFoxの開発者は、安全性の追跡が体系的、つまり一貫している必要があることを恐れて理解する必要があります。
透過的なプロキシの問題がそれらを非常に煩わせるのであれば、FlashとJavaは禁止されるべきです。
そして、それは安いPRトリックのように見えます：
「見て、セキュリティが気になります。 ブラウザに穴の開いたFlashを残しましたが、WebSocketを無効にしました。これで安全です。」
Pss
少し調整しました。 私はそれがより明確になったことを願っています...
だから、ITの前線からの最新ニュース。 彼らは衝撃的です。
Adobe Flashには深刻なオープン脆弱性があるため、すべての主要なブラウザーがサポートを拒否しました。 はい、はい、ネットワーク上にフラッシュはもう存在しません。 これは私の庭のベンチに座っているすべての主要な祖母によって述べられました。
9までのすべてのバージョンのInternet Explorerに深刻なオープン脆弱性があるため、すべてのIEユーザーはネットワークへのアクセスを拒否します。 レイアウトデザイナーにとっての新しい悪夢-IEのさまざまなバージョンのサイトバージョンを維持する必要がなくなりました。 悪夢！ 取得したスキルをどうするか？ 管理人の空きスペースはどこですか？
Windowsの深刻なオープン脆弱性のため、すべてのブラウザーメーカーはこのプラットフォームのサポートを拒否しています。 「はい、はい、ReactOSに切り替えています」と、大手市場の大手企業の主要ブラウザの主要開発者が独占インタビューで確認しました。
最後に、Industrialでの冬用タイヤの開発責任者の発表は、神格化でした。 「タイヤを取り付けた車で発生した1829783の事故を分析しました。 そして、彼ら全員が丸い車輪を持っているという結論に達しました。 運転の安全性が私たちのすべてなので、丸い車輪を捨てて四角い車輪に進むことにしました。 „
冗談を言って、それで十分です。 それを理解してみましょう。
まず第一に、Adam Barthの記事は「透明なプロキシ：脅威か脅威か？」というタイトルでした。 つまり、作成者はWebSocketプロトコルではなく、「透過的なプロキシ」を調べます。
これは何ですか 簡単です-クライアントがプロキシを明示的に指定した場合、これは明示的なプロキシです。 また、ブラウザのリクエスト（ホテルなど）が、フィルタリング用の特別なプロキシによって感知されないように傍受された場合、これは「透過的な」プロキシになります。
問題（著者による）は次のとおりです。 透過プロキシがHTTP要求を受信しました。 プロキシは透過的であるため、クライアントから特定のIPアドレス（サーバー）に送信された要求をインターセプトします。 同時に、HTTP要求自体でホスト要求を指定することもできます。 ロジックの観点から、プロキシはリクエストを送信先、つまり送信元IPに送信する必要があるようです。 ただし、著者によると、一部のプロキシは、ホストリクエストヘッダー内のホストに対応するIPアドレスにHTTPリクエストを送信します。
「正しさ」の観点からこの決定については説明しません。 一部の透過プロキシが、Hostヘッダー内のホストにリクエストをリダイレクトするとします。 これから何が続きますか？
作者はさらに別のドキュメントについて言及します 。
悪意のあるサイトが、生のソケットを使用する許可を受けたブラウザーにFlashアプリケーションをダウンロードした、つまり、単純に言えば、Flashアプリケーションはダウンロード元のサーバーへのTCP / IP接続を使用できると仮定します。 透過プロキシは、そのような接続をブラウザから区別できますか？ できません。 Flashアプリケーションが正しいHTTPリクエストを生成し、TCP経由でサーバーに送信すると、透過プロキシはブラウザがこのリクエストを送信することを決定します。 悪意のあるフラッシュアプリケーションは、悪意のあるホストを指す悪意のあるリクエストにHostを挿入します。
そして今、プロキシがホストフィールドで（悪意のある）ホストへの応答を受信するほど愚かである場合、このサーバーから何かがスリップされ、プロキシは元の（良い）ホスト（IPアドレスが最初にリクエストを送信しました）。
次の2つの問題があります。
1.悪意のあるフラッシュアプリケーションは、ダウンロード元のWebサーバーだけでなく、どのWebサーバーにもアクセスできるようになりました。
2.プロキシが応答をキャッシュする場合、クライアントから正常なサーバーへの後続の要求は、悪意のあるキャッシュされた応答を受け取ります。
そのため、 透過プロキシがホストヘッダー内のホストにリクエストをリダイレクトする場合（リクエストが送信されたIPアドレスを使用する代わりに）、透過プロキシキャッシュを侵害してSOPフラッシュアプリケーションを破壊する問題が発生します。
また、
4.2.3 DNS requirements
In transparent proxy configurations, client systems MUST be
able to resolve server names belonging to remote networks. This
is critical since the proxy will determine the target server
from the destination IP address of the packets arriving from
the client.
つまり、標準では、ホストフィールドからではなく、リクエストのIPアドレスを取得する必要があると明確に述べています 。
繰り返しますが、WebSocketのせいではないようです。 さて、著者による元の記事に戻ります。
著者は実験を行った。 彼らは、同様のスキーム、つまり「異なる」ホストでHTTPリクエストを送信しようとする広告バナーを人々に配りました。 フラッシュアプリケーションとJavaアプリケーションの両方が使用されました。 実験では、「悪意のある」Flashを使用するリクエストの2.2％（36305の803）および「悪意のある」Javaクラスを使用するリクエストの3.6％（33820の1212）が、IPアドレスではなくHTTPヘッダーのホストにリダイレクトされました。
さらに、作成者はWebSocketプロトコルを使用してプロキシを「だます」ことを試みます。 透過プロキシがWebSocketについて何も知らない場合、クライアントは次の形式のメッセージをWebSocketハンドシェイクに送信できます。
GET /sensitive-document HTTP/1.1
Host: victim.com
不幸なプロキシはWebSocketについて何も知らないため、これは別のHTTPリクエストであると判断します。 そして、彼はvictim.comに「行き」、そこに転送します。 著者の実験は、プロキシの2.8％がこれを行ったことを示しました（49218のうち1376）。 さらに、実験は本質的に繰り返されました。
したがって、WebSocketが安全でないという主張は誤りです。
透明なプロキシがWebSocketを知らず、RFC 1919に違反するため、セキュリティ違反が発生します 。
この調査の著者は、WebSocketにHTTP CONNECTコマンドを使用するというソリューションを提供しています。 彼らの実験は、_all_透過プロキシがCONNECTをうまく機能させることを示しました。 彼らは内部にHTTPSデータがあると信じており、それを解析しようとはしません。 要求はソースIPに送信されます。
まとめると。
透過プロキシの約3％が、HTTPリクエストをリクエストヘッダーのHostフィールドで指定されたホストIPアドレスにルートします。 これは、RFC 1919標準の違反であり、ルートは、要求が送信された送信元IPアドレスで実行する必要があります。
この動作により、悪意のあるFlashアプリケーション、Javaアプレット、またはJavaScriptが任意のサイトにアクセスし（同一生成元ポリシーの違反）、これらのプロキシのキャッシュを侵害することができます。
悪意のあるJavaScriptスクリプトは、ブラウザがWebSocketをサポートしている場合にのみ害を及ぼす可能性があります。 FlashアプリケーションとJavaアプレットは、WebSocketブラウザーのサポートを必要としません。
ハンドシェイクWebSocketでCONNECTコマンドに切り替えると（いくつか改善されています）、WebSocketの場合に「穴を閉じる」ことができます...
...ただし、SOPを破り、プロキシキャッシュがRCF 1919を破るまでプロキシキャッシュステイをコメントするために、悪意のあるフラッシュとJavaアプリケーションを使用します。
気晴らしのための画像。
PS
追加するのを忘れました。 OperaおよびFireFoxの開発者は、安全性の追跡が体系的、つまり一貫している必要がある
透過的なプロキシの問題がそれらを非常に煩わせるのであれば、FlashとJavaは禁止されるべきです。
そして、それは安いPRトリックのように見えます：
「見て、セキュリティが気になります。 ブラウザに穴の開いたFlashを残しましたが、WebSocketを無効にしました。これで安全です。」
Pss
少し調整しました。 私はそれがより明確になったことを願っています...
All Articles