WebSocket は、単一の TCP 接続に全二重チャネルを提供する HTML5 機能です。常時接続機能により、B/Sモードでのリアルタイムアプリケーションの構築が可能です。 Websocketはチャット機能を備えたWEBアプリケーションでよく使われます。
次の図は、APT 攻撃で使用される WebSocket を非常に詳しく示しています:
同一生成元ポリシー: 同一生成元とは、ドメイン名、プロトコル、およびポートが同じであることを意味します。ブラウザは同じブラウザの異なるタブをチェックして、同じソースからのスクリプトをタブ間で実行できるようにします。
Origin フィールド: POST リクエストを送信するときに、ブラウザーは Origin フィールドを追加することがあります。この Origin フィールドは主に、最初のリクエストが開始された場所を識別するために使用されます。ブラウザがオリジンの場所を特定できない場合、送信されたリクエストの Origin フィールドの値は空になります。
IronWASP: ユーザーがセキュリティ スキャンをカスタマイズし、Python/Ruby を使用してプラグイン システムを定義できるオープン ソースの WEB テスト プラットフォーム。関連する概要については、 http://www.php.cn/
ZAP (Zed Attack Proxy) を参照してください。これは、さまざまなツールを統合し、WEB アプリケーションの脆弱性を検出できる侵入テスト フレームワークです。 : http://www.php.cn/
最近、複雑なメニューオプションと機能を備えたWEBアプリケーションのセキュリティ評価を実施しました。このアプリケーションのほとんどの操作は Web ソケットを使用します。これは、そのアクションのほとんどが http プロキシ ログに記録されないことを意味します。
まず、ホームページを開いた後、Web サイトは JS スクリプトと CSS ファイルを含む静的な Web ページを読み込みます。その後、通信対話全体が Websocket モードに切り替わり、ブラウザとサーバーの間に WebSocket 接続が確立され、Web サイトに表示されているすべての HTML リソースが読み込まれます。リンクをクリックするかフォームを送信すると、ブラウザはいくつかの WebSocket メッセージをサーバーに送信します。サーバーはこれらのメッセージを処理した後、WebSocket を通じてフィードバックし、クライアントのブラウザーに新しい HTML コンテンツが表示されます。
現時点で WebSocket メッセージがやり取りされると、通信量が非常に膨大になります。それらの間では、毎秒ハートビート検出パケットのやり取りが行われます。しかし、既存のツールは私の要件を満たしていなかったので、Websocket メッセージ分析デバイスと WebSocket クライアントを IronWASP に追加して、Websocket を識別し、その脆弱性を回避できるようにする必要がありました。詳細については、こちらをご覧ください。
このアプリケーションをテストしているときに、WebSocket のクロスサイト WebSocket ハイジャッキングの脆弱性 (Christian Schneider が開発) があることがわかりました。もちろん、テスト方法を紹介する前に、この脆弱性の影響について説明します。関連する Websocket アプリケーションをテストする前に、まず準備をする必要があります。
同一オリジン ポリシー (SOP) はブラウザーを介して WebSocket に適用されないことを全員が理解する必要があります (同じブラウザーでは、SSL で保護されたページでは非 SSL WebSocket パスが許可されません) )、テストしたアプリケーションはセッション認証として http Cookie を使用し、ブラウザ経由で WebSocket によって送信されるメッセージにはセッション ID やランダム パラメーターがありません。
このように、ユーザーが脆弱性のある WEB アプリケーションにログインし、http://www.php.cn/ (攻撃者の Web サイト) を開いた場合、同じブラウザーで http://www.php .cn / は、この脆弱なアプリケーションを通じてアプリケーションのサーバーとの WebSocket 接続の確立を試み、ブラウザを通じて有効な認証セッション ID を含む要求パケットを送信することができます。したがって、攻撃者の Web サイトによって確立された WebSocket 接続には、アプリケーション自体と同じ権限が与えられます。
アプリケーション全体が WebSocket 上で実行されるため、WebSocket をハイジャックすることはユーザーのセッションをハイジャックすることと同じです。したがって、この脆弱性は、保存されたクロスサイト スクリプティングの脆弱性と本質的に同じです。
これが悪いことだと思うなら、場合によっては WebSocket クロスサイト スクリプティングがユーザー システム上でリモート コード実行を実現することもできると聞いたら、もっと驚くでしょうか。IPython Notebook の事例を参照してください。
テストする前に、最初に行う必要があるのは、アプリケーションに WebSocket が存在するかどうかを確認することです。幸いなことに、これを行うには次の 3 つの点だけを知っておく必要があります:
1. WebSocket URL 接続は通常、ws:// または wss:// で始まります。
2. 確立された接続の Origin ヘッダーを検出する必要があります。Web ページは、Origin フィールドを通じて確立された WebSocket リンクである可能性があります。
3. ブラウザとサーバー間で送信されるメッセージから、通常の WebSocket 接続の特性を確認できます。
下の図は、IronWASP ログから Origin フィールドの値と WebSocket の URL 値を取得する方法を示しています。
この情報を取得したら、いくつかの特別な方法を使用して、クロスサイト WebSocket ハイジャックの脆弱性を検出できます。ここに 3 つの簡単な例を示します:
ここで、Burpsuite が WebSocket メッセージをキャプチャおよび記録できることを言及する必要があります。 ZAP と IronWASP は、WebSocket リクエストを再生できるソフトウェアとして私が知っているものです。
burpsuite では、WebSocket メッセージを再生することはできませんが、限られた条件下で WebSocket ハンドシェイク パッケージが成功したかどうかを検出することはできます。テストするには、WebSocket アップグレード要求パケットを分析する必要があります。パケットは http または https 経由で送信されるため、再生できます。
次のスクリーンショットは、Burpsuite リプレイヤ ([繰り返し] タブ) の記録で、WebSocket 接続の有効なリクエストと応答を示しています:
この脆弱性をテストするには、作り直したものを使用して別の脆弱性を送信する必要があります。オリジンヘッダーリクエストパケット。応答パケットに「101 Web Socket Protocol Handshake」マークがある場合、WebSocket が正常に確立されたことを意味します。
接続が正常に確立されない場合、アプリケーションは外部 WebSocket 接続を拒否するため、この脆弱性がないことを意味します。確立が成功したら、アプリケーションに WebSocket クロスサイト ハイジャックの脆弱性があるかどうかを確認するテストの次のステップを開始できます。ここで説明する必要があります。接続が確立されている場合でも、サーバーが WebSocket メッセージに応答することを確認した後でのみ、アプリケーションが脆弱であると証明できます。これは、開発者がオリジンの検出と接続機関の認証を同時に有効にする可能性があるためです。したがって、実験では次のような状況が発生する可能性があります。確立された接続は永久に維持できますが、外部ソースを持つオリジンは認証を通過できません。
ZAP は WebSocket メッセージを再生できますが、私が理解している限り、Origin ヘッダーは変更されません。以下で紹介する方法は、CSWSH (WebSocket クロスサイト ハイジャック) を通じてより多くのものを取得する方法に関する一般的な科学を提供します。
テストする必要がある WEB アプリケーションを開いてログインし、同じブラウザーで新しいタブを開いて http://www.php.cn/ にアクセスします (シミュレートされています)ハッカー Web サイト )、WebSocket の URL アドレスを入力し、Web ページ上の [接続] ボタンをクリックします。接続が確立されたら、このページを通じて WebSocket サーバーにメッセージを送信できます。有効なセッションによって送信されたメッセージを再生し、サーバーの応答パケットを確認する必要があります。
サーバーからの応答が、以前の有効なセッションによって送信された通常のパケットと同じである場合、アプリケーションに WebSocket クロスサイト ハイジャックの脆弱性がある可能性があることを意味します。
IronWASP は、最も基本的な検出についても自動スクリプト チェックを提供します。
上記の Origin のテスト方法で使用したサーバーは http://www.php.cn/ です。Origin の値をより柔軟に設定したい場合は、IronWASP クライアントを使用できます。これにより、Origin 値をカスタマイズして WebSocket 接続をテストできます。
クライアント機能は次の状況で使用できます:
1. アプリケーションはオープンオリジンからの WebSocket 接続を許可します
2. アプリケーションはローカルホストおよびイントラネット IP からの Origin フィールド値を許可します
このアプローチは、開発者とアプリケーションの内部テストを容易にすることを目的としています。 IronWASP クライアントを使用すると、イントラネット IP またはローカルホストをオリジンとして有効にできるかどうかを試すことができます。可能であれば、いくつかのトリックを使用して実際の環境でこの脆弱性を悪用できる可能性があります。たとえば、アプリケーションがオリジン フィールドとして http://127.0.0.1:8080 を許可している場合、次のようにすることができます。 被害者がたまたまローカル ポート 8080 で実行されている WEB アプリケーションを持っていて、それにクロスサイトがある場合スクリプトの脆弱性。これらの条件が満たされた場合、ハッカーはまず WEB アプリケーションに対してクロスサイト攻撃を実行し、次にターゲット アプリケーション サーバーへの WebSocket 接続を確立できます。
localhost を使用するか、イントラネット IP を使用して Origin ヘッダーをテストし、自動検出用のクライアント スクリプトを使用してアクションを簡単にします。 IronWASP を使用すると、Python または Ruby を使用してカスタム スクリプトを実装できます。
次のスクリプトは、Origin ヘッダーに入力されたイントラネット IP アドレスを個別に検出し、サーバーがそれを認識するかどうかをテストできます:
import clr
clr.AddReference("WebsocketClient.exe")
from WebsocketClient import *
def check_conn(origin):
print "Testing origin - " + origin
ws = SyncWebsockClient()
ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212")
ws.Send("first message to send")
msg = ws.Read()
ws.Close()
if msg == "message that is part of valid session":
print "Connection successful!!"
return True
else:
return False
def check_nw():
for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]:
for ip in Tools.NwToIp(nws):
if check_conn("http://" + ip):
break
check_nw()
以上がセッションを完全に制御する方法の詳細な紹介 WebSocket のクロスサイト ハイジャックのグラフィック コードの詳細な説明を見てみましょう。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
