脆弱性の攻撃手法としてCSRF（クロスサイト・リクエスト・フォージェリ）は知っている人も多いと思う。
2019年ころから類似した攻撃手法としてSSRF（サーバサイド・リクエスト・フォージェリ）という攻撃がクローズアップされ始めた。
米金融大手 Capital Oneの大量個人情報流出が発生したのもちょうどその頃である。
近年ではOWASP TOP10:2021でも10位にランクインしている。
また、さらに新しい話だと2023年1月17日にAzureのブログでSSRFの脆弱性4つが報告され、修正対応が行われていたと発表があった。
今回はこの SSRFという攻撃手法について少しだけ掘り下げてみた。
どのような攻撃手法なのか？
CSRFが別のサイトに対してのリクエストを偽装するのに対して、SSRFはサーバサイド内でのリクエストを偽装する。
そのため、通常アクセス出来ないサーバサイドから先の別のサイト（内部サイトやマスター系のAPI情報、機密情報ファイルなど）にアクセス出来てしまう。
クラウドならではの危険性も
クラウドで利用されているIMDS（Instance Metadata Service）にアクセスされると、クラウド内部の秘匿情報が洩れてしまう可能性が出てくるためより一層危険である。
似たような攻撃手法について
各攻撃手法の詳細は割愛する。
- OSコマンド・インジェクション
- SSRFをコマンドで実行可能な点で似ている（広義でSSRFも含んでいると考えてもよい）
- XML外部実体攻撃（XXE）
- サーバサイドのリソースにアクセスする点で似ている
- オープンリダイレクト
- HTTPの通信先がサーバサイドか外部かという点で似ている（SSRFはHTTP通信とは限らない）
防ぐためにはどうするのか？
仕様検討で防御
サーバ内部でリクエストを発行する処理を実装（有効化）しない。
（内部で別APIをコールするような構成が多い最近のWebシステムでは難しいと思われる。）
リクエスト発行先を限定（固定）して防御
サーバ内部で発行するリクエストは必ず固定のドメインに限定する。
（DNS Rebindingなど別の攻撃と合せることで突破可能なので完全な対策ではないが、通常の対策としては十分。）
URL文字列を解析して防御
任意のURLへアクセスが必要な機能であれば、アクセス先がサーバ内部にならないようにURLをパースしてチェックする。
（パースに利用する言語や関数次第では処理をすり抜けてしまう可能性がある。）
徳丸浩の日記 – SSRF(Server Side Request Forgery)徹底入門
→ URLをパースする際の問題
ネットワークを限定して防御
アプリケーションでの対策以外にネットワーク、OSレベルで制限をかける。
（IMDSに関してはクラウド側でも防御策を講じているのが完全ではない模様。）
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
まとめ
任意のURLへのアクセスが必要な場合にはSSRFの攻撃対象となりやすく固定的な方法で防御が難しいのが実情である。
アプリケーション側での対策を実施した上で、所謂ゼロトラストの考え方に近いですが、攻撃される前提でWAFやIDSやIPSなどで検知や防御が出来る対策を施して置く事も重要である。