SSRF攻撃とは？DNSが悪用される仕組み

サーバーサイドリクエストフォージェリ（SSRF）は、攻撃者がサーバーをだまして、攻撃者に代わってHTTP（またはその他のネットワーク）リクエストを送らせる攻撃です。送信先は、アプリケーションの開発者ではなく、攻撃者が選んだ宛先になります。典型的な入口は、ユーザーが指定したURLを取得する機能です。画像のインポート、Webhookの送信先、リンクのプレビューなどで、攻撃者は公開リソースではなく、内部インフラを指すURLを指定します。

攻撃のなかでDNSが果たす役割

素朴な防御策は、指定されたURLのホスト名が内部アドレスに見えるかどうかを確認することです。これは簡単に回避されます。攻撃者は公開ドメインを登録し、そのDNSレコードを内部IPに向け、ごく普通に見えるホスト名をサーバーに渡します。検証が見るのはIPではなくドメインです。危険な部分は、DNSの名前解決が行われたあとにしか現れません。それは多くの場合、実際にリクエストを送るHTTPクライアントライブラリの奥深くで起き、事前の検証ステップをはるかに過ぎたところです。

実効性のある防御とは

• リクエストを送る前に、ホスト名を自分で明示的に名前解決する。HTTPクライアントに、見えないところで解決させない。
• 解決されたすべてのアドレス（ドメインは複数を返すことがあるため、すべて）を、プライベート、ループバック、リンクローカル、クラウドメタデータのブロックリストと照合する。
• 最初に返された1つだけを確認するのではなく、解決されたアドレスのどれか1つでも許可されていなければ、リクエストを拒否する。
• 入力時だけでなく、リクエスト時にも再検証する。別記事で説明しているDNSリバインディングの穴をふさぐためで、実際にはSSRFとリバインディングが組み合わされることも多い。

クラウドのメタデータエンドポイントは、特に注意が必要です。多くのクラウドプロバイダーでは、VM内部から特定のリンクローカルアドレスにリクエストを送ると、認証情報、インスタンスのメタデータ、マシンの外部からは決して到達できないはずの設定が返ってくることがあります。SSRFとメタデータエンドポイントを標的にした攻撃の組み合わせは、実際に最もよくあり、最も影響の大きい攻撃の連鎖の1つです。そして、それは毎回、一見ごく普通のドメイン名から始まります。

アドレスではなく文字列を確認するフィルターは機能しない

IPアドレスには、ほとんどの検証コードが想定している以上に多くの有効な文字列表現があります。「127.0.0.1」や「localhost」への文字列の一致で書かれたフィルターは、以下の別の表記をすべてそのまま通してしまいます。どれも、確認対象の文字列には見えないからです。

唯一確実な防御は、まずアドレスを実際の数値に解析し、その値に対してブロックリストを評価することです。このツール自身のリゾルバーも、アドレスがどう書かれていたかというパターンマッチではなく、この方法を採っています。リゾルバーは、元のホスト名のレコードがどんな形式で符号化されていても、正規化されたアドレスを返します。攻撃者が選びうるあらゆる形式の生の文字列を検証しようとするより、先に名前解決して、解決結果を検証するほうが堅牢なのは、まさにこのためです。

リダイレクトも、よくあるもう1つの回避手段

最初のURLを正しく解決して検証しているシステムでも、HTTPリダイレクトで突破されることがあります。承認済みの公開URLへのリクエストが、内部アドレスを指す302で応答することがあり、リダイレクトを自動的に追跡するHTTPクライアント（ほとんどのライブラリの既定の動作）は、最初のときに通った検証をやり直すことなく、2つ目のリクエストを平然と送ります。最初に1回だけ検証して、リダイレクトの処理を下層のHTTPクライアントに任せるSSRF対策には、DNSの名前解決が生む穴とまったく同じ形の穴があります。対処法も同じです。1度通ったURLが今後も安全な場所を指し続けると信じるのではなく、リダイレクトを追跡する前に、毎回明示的に再検証してください。