SSRF 保護のバイパス

こんにちは、

最後に投稿してからしばらく経ちました。私は、プライベート プログラムを探しているときに見つけたきちんとした SSRF バイパスを共有したいと考えていました。

SSRF は、サーバー側のリクエスト フォージェリの略です。サーバー側のリクエスト フォージェリにより、攻撃者は HTTP リクエストを悪用して、サーバー内部または内部ネットワークに関する情報を要求できます。

注意すべきことは？url= next= host= image= img= などのパラメータ。サーバーに対して Web リクエストを行っているように見えるもの。これは、リクエストを内部的に指すために悪用される可能性があります。

脆弱なエンドポイントをどのように見つけましたか?

プライベートプログラムで狩りをしている間、私は大規模な偵察を行っていました. 私は、主に censys から取得したサブドメインの膨大なリストを集めました。この後、総当たり攻撃を行い、すべてのホストの URL をウェイバック マシンで検索しました。当時、ssrf に重点を置いていたので、ディレクトリとエンドポイントの出力を収集し、「proxy.php」を grep しました。幸いなことに、私はヒットしました。

リクエストを調べたところ、これは指定された URL へのアウトバウンド HTTP リクエストを作成していました。げっぷコラボレーターのリンクを入力した場合、ルックアップを受け取りませんでした。127.0.0.1 と内部ホストの IP 表記を入力して、通常の基本を試してみました。リクエストに Web サイトのホスト名が含まれていない限り、各リクエストはブロックされました。

ここからが技術的な話になります。げっぷの共同作業者と一緒に、ブラウザの資格情報のフォーマットとともにリクエストを送信すると、たとえば url=https:// hostnameofwebsite.com@myburpcollablinkと返ってきました。

次に、これを変更して悪用しようとしました.

私は最近、Google で ssrf ビデオを見たところ、\ を使用すると、最初のホストの後にバックエンドでの解析が停止することが説明されていました。フロントエンドはリクエストを hostnameofwebsite を myburpcollablink への認証情報として解釈しますが、バックエンドはフロントエンドのリクエストのみを処理するため、hostnameofwebsite. ここで私はそれを変更し、url=http://169.254.1698.254\@hostnameofwebsite を使用しました。

説明しましょう。169.254 は、AWS メタデータの内部 IP アドレスです。フロント エンド リクエストは、これを hostnameofwebsite への資格情報として 169.254 として認識しています。これは、hostnameofwebsite がリクエストに含まれている必要があるため、フロント エンド チェックを通過します。バックエンドはこの形式を無視し、次のように処理します。http://169.254.169.254\次に、リクエストだけを遮断して渡します。

解決したためクローズ