【要約】「URLを入力するだけ」の診断ツールを作ったら、自分がSSRFの入り口になりかけた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が診断ツールを構築する際、ユーザー指定のURLへリクエストを送る機能がSSRFの脆弱性を生む。対策を誤ると、サーバーが攻撃者の代理人として動作してしまう。
- ・AWS IMDSへのアクセスによる認証情報の漏洩。
- ・VPC内の内部サービスへのポートスキャンへの悪用。
- ・文字列ベースのブラックリストによる不完全な防御。
// Approach
開発者は、ホスト名の文字列ではなく、名前解決後のIPアドレスを検証する手法を採用した。これにより、ドメイン名に隠された不正なIPへのアクセスを遮断する。
- ・
socket.gethostbyname等を用いてDNS解決を実行。 - ・解決されたIPがプライベートレンジに属するか判定。
- ・DNS Rebinding対策として、リクエスト直前に毎回名前解決を実施。
- ・LambdaとLaravelの両層で独立したチェックを行う多層防御。
// Result
開発者は、防御と検知のロジックを統合し、ツールの安全性を高めた。防御のために構築した仕組みが、そのまま診断機能の核となった。
- ・自身のサーバーを保護するロジックを、対象サイトの脆弱性検知に応用。
- ・
SSRF_PARAMS等を用いた検知ロジックの確立。 - ・防御と検知が「表裏一体」であるという設計思想の実現。
Senior Engineer Insight
> 極めて実践的な知見である。文字列チェックではなく、名前解決後のIP検証を行うのは鉄則だ。DNS Rebindingを考慮し、キャッシュを利用せずリクエスト直前に解決する実装は、実戦的である。多層防御の観点も高く評価できる。防御と検知のロジックが共通している点は、設計の美しさを感じさせる。