ソース：
脆弱性：SSRF
訳：
ssrfとは何ですか？
ほとんどの読者は ssrf とは何かを知っていると思いますが、簡単に説明するために、portswigger を見てみましょう。
サーバー側リクエスト フォージェリ (SSRF とも呼ばれる) は Web セキュリティの脆弱性であり、攻撃者がサーバー側アプリケーションに、攻撃者が選択した任意のドメインへの HTTP リクエストを実行させることを可能にします。
私はプログラムに取り組んでいましたが、ターゲットの名前を公開する権限がないので、それを redacted.com と呼びましょう。
このプログラムを少しいじった後、次のようなエンドポイントに到達しました ~> https://redacted.com/api/download-pdf?url= ”http://SomeThing.com”。
私はすぐにBurp コラボレーターを起動し、デフォルトの URL を自分の URL に置き換えました。
幸いなことに、Burpコラボレーターは HTTP リクエストと DNS リクエストを受信し、それに応答してげっぷページを受け取りました。
その後、最初に頭に浮かんだのは、 http://localhostをそこに配置してみようということでした。
しかし、私は得ました：
これには保護策がありましたが、私はあきらめず、ローカルホストの制限をバイパスするためにすべての方法を実行し、これらのペイロードをすべて試しました。
http://[0:0:0:0:0:ffff:127.0.0.1]/thefile
その他にも、https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery で見つけることができるものがたくさんあります。
「file:///」、「sftp://」、「gopher://」などの他のプロトコルも試しました。
どれも機能しません! :(
しばらくすると、AWS メタデータ インスタンスを取得するために「http://169.254.169.254/」を試してみてはいかがでしょうか?ということが頭に浮かびました。
それで私はそれをしました、そして私は得ました:
サーバーが SSRFの元のリクエストをフィルタリングしているが、そのリクエストへのリダイレクトレスポンスはフィルタリングしてしていない可能性があります。
たとえば、サーバーは次のような方法で SSRF に対して脆弱になります。 url=https://www.google.com/。そのサーバーはURL param をフィルタリングしている可能性があります 。
ただし、Python サーバーを使用して リダイレクト先の場所に302 で応答すると、127.0.0.1 などのフィルタリングされた IP アドレス、もしくはフィルタリングされたプロトコル、gopherなど、にアクセスできる可能性があります。
そこで私は Django サーバーを起動し、このコードをサーバーに挿入しました。
このリクエストを送信し、製品を取得しました。それから、「http://169.254.169.254/latest/meta-data/iam/security-credentials/ YOUR-PROD-HERE」Django サーバーに置きました。
そして最後に私は次のものを手に入れました：
ほなほな。
