サーバーサイドリクエストフォージェリ
サーバーサイドリクエストフォージェリの脆弱性は、ユーザーがアプリケーションに攻撃者が指定したドメインに HTTP リクエストを送信させることができる場合に発生します。アプリケーションがプライベート/内部ネットワークにアクセスできる場合、攻撃者はアプリケーションに内部サーバーにリクエストを送信させる可能性もあります。
実際にどのように見えるかをよりよく理解するために、いくつかの例を挙げてこれを詳しく見ていきます。
ページのプレビューやエクスポートなど、ユーザーから提供された URL の画像を生成する API を考えてみましょう。
TS
url = request.params.url としましょう。
レスポンス = http.get (url); とします。
レンダー=レスポンス.render ();
レンダー.export (); を返します。
URL パラメーターはユーザーが制御するため、攻撃者は任意のURLに簡単にアクセスできます。URL へのアクセスに使用されたライブラリによっては、「file://」スキームを使用したローカルファイルである場合もあります。
SSRFの脆弱性を悪用する一般的な方法は、SSRFの脆弱性を悪用して、AWS APIの認証情報を含む可能性のあるAWSメタデータAPIにアクセスすることです。これにより、アカウント内の他の AWS リソースにさらにアクセスできるようになる可能性がありますが、ご想像のとおり、これは理想的ではありません。
緩和策
SSRFの脆弱性を軽減することは非常に難しい場合があり、問題のコードが何を達成しようとしているかに大きく依存します。要件に応じて、実施できる緩和策はさまざまです。
ユーザー定義の URL は避けてください
場合によっては、ユーザーが任意の URL を提供する必要がない方法で機能を実装できることがあります。これが可能ならば、SSRF のリスクを軽減する最も効果的な方法と言えるでしょう。
機能を最小化
PDF エクスポート機能を実装する場合、単にヘッドレスブラウザを使用してページのスクリーンショットを撮りたいと思う人もいるかもしれません。ブラウザーは複雑で、ブラウザーが公開する機能や攻撃対象領域の数が非常に多いことを考えると、これは必ずしもお勧めできません。
目の前の作業に適したツールを使用することが重要です。場合によっては、単純な HTTP クライアントで十分でしょう。機能を最小限に抑え、攻撃対象領域や攻撃経路を最小限に抑えるためにできることは常にあります。たとえば、HTTP クライアントの場合:
- 次のリダイレクトを無効にする
- HTTPS 以外のスキームをすべて無効にする
いくつかの落とし穴があります
リダイレクトとインラインフレーム
プライベートリソース (IP アドレスまたは内部ホスト名) の SSRF を防ぐ一般的な方法は、ユーザーから提供された URL を解析し、「拒否リスト」を使用して機密リソースへのアクセスを防ぐことです。
この方法は、クライアントが HTTP リダイレクト、HTML/JavaScript リダイレクトに従ったり、iframe のような複雑な要素をレンダリングしたりするシナリオではバイパスされる可能性があるため、ほとんどの場合効果がないことに注意してください。
攻撃者は、HTTP 301/302、HTML Metaリダイレクト、ロード時にJavascriptで現在のURLを設定する方法、または内部リソースを示すiframeを埋め込む方法のいずれかを使用して、機密リソースにリダイレクトするページをホストする脆弱なアプリケーションへのURLを提供する可能性があります。これにより、元の URL を検証しようとする試みが事実上回避されます。
DNS リバインディング
DNS 経由で別の「タイプ」のリダイレクトを行うこともできます。SSRF 攻撃を防ぐ一般的な方法の 1 つは、次のことです。
- 提供された URL を解析します
- ホスト名を取得し、DNS ルックアップを行います
- URL が内部/プライベート IP に解決される場合は拒否し、パブリック IP の場合は URL を受け入れる
この方法は「DNS再バインド」の影響を受けやすいため、あまり効果的ではありません。DNS 再バインドが機能するのは、リモートホストが TCP 接続を閉じたときの、ほとんどのネットワークスタック (Linux や Windows など) の標準的な動作によるものです。
リモートホストが強制的に接続を閉じると、別の DNS クエリを実行して IP アドレスを再解決した後に再接続を試みます。
これにより、攻撃者は次のことが可能になります。
- 「rebinding.attacker.com」の DNS エントリを、非常に短い TTL (存続可能時間) で HTTP ポートが開いているパブリック IP アドレスを使用して作成します。
- 脆弱なアプリケーションに URL (例:https://rebinding.attacker.com/) を送信してください。解決された IP がプライベートでないこと、つまりプライベートではないことを確認し、安全であることを確認したうえで、要求された操作を続行します。
- HTTP 接続が確立されると、「rebinding.attacker.com」の DNS エントリが内部 IP アドレスに変更されます。
- HTTP 接続は強制的に閉じられます
- これにより、アプリケーションが「rebinding.attacker.com」の IP アドレスを再解決するようになり、これが内部 IP アドレスを指すようになりました。
- IP解決保護はすでに行われており、DNSエントリの再解決と再接続はすべてカーネルで行われるため、アプリケーションはIPが変更されたことを認識していません。
これにより、プライベート IP アドレスに変換される URL の提供に対する保護が効果的に回避されます。
IPv4 と IPv6
「拒否リスト」を回避するもう1つの一般的な方法は、IPv6の使用です。すべての IPv4 アドレスは IPv6 アドレスで表すことができるため、アクセスしたい IPv4 アドレスにも対応する IPv6 アドレスを使用することで、拒否リストをバイパスできることがよくあります。
Secure coding made practical
Explore secure coding guidelines to understand and mitigate software vulnerabilities like the OWASP Top 10, and dive into guided training Missions to practices in real-world app simulations.