脆弱性コラム - 第15回
サイト脆弱性をチェックしよう！ -- 第15回：SSRF（サーバサイド・リクエストフォージェリ）とは
サーバサイド・リクエストフォージェリとは
前回解説したCSRF(クロスサイト・リクエストフォージェリ)では攻撃者が被害者となるユーザに意図しないリクエストを送信させ、被害者の権限で処理を実行させてしまう攻撃であった。一方、サーバサイド・リクエストフォージェリはユーザではなくサーバに意図しないリクエストを送信させ、外部には公開していないサーバに処理を実行させてしまう攻撃である。
CSRFの図
SSRFの図
攻撃の背景
企業が運用するWebアプリケーションは、一般的に複数台のサーバで構成される。特に近年ではクラウドサーバの利用やマイクロサービスという手法が普及しており、一つのWebアプリケーションで使用するサーバ台数がさらに増加する傾向にある。複数台のサーバを使用する場合、利用者の操作を受け付ける外部公開サーバ以外はユーザから直接操作できないよう、アクセス制御を行う必要がある。（直接操作できてしまった場合はアクセス制御不備の脆弱性となる）
この時ネットワークセグメントごとにアクセス制御を行う方法がある。この方式の場合、外部と内部で行われる通信は制御できるが、内部のサーバ同士の通信は制御していないことが多い。
外部公開サーバに開発者が意図していない操作を行うことで、内部のサーバ同士の通信として不正な処理を要求させる攻撃が、サーバサイド・リクエストフォージェリである。
サーバサイド・リクエストフォージェリの攻撃手法
サーバサイド・リクエストフォージェリには様々な攻撃パターンがあるが、最も典型的な例の一つとして任意のURLに通信を送信できる機能を悪用したケースを紹介する。- 攻撃者がフロントエンドサーバから任意のURLに通信を送信できる機能を使用して、管理サーバ向けの通信を送信させる。
- フロントエンドサーバから管理サーバに向けて通信が送信される。
- 管理サーバはフロントエンドサーバから送信されているため、アクセス制御の対象とならず処理を受け付ける。
- 管理サーバの機能が実行される。
正常な利用方法
サーバサイド・リクエストフォージェリ攻撃
この説明では単純化のためにHTTPプロトコルを記載しているが、原理的にはすべてのプロトコルで攻撃が可能である。
どのようなWebサイトで注意が必要か
サーバサイド・リクエストフォージェリには外部公開サーバと、内部サーバ両方の機能が影響する。○ 外部公開サーバ
下記のいずれかの場合に、サーバサイド・リクエストフォージェリーを呼び出す危険がある。- 任意のURLに通信を送信できる機能にSSRF脆弱性がある
スクレーピング、クローリング、魚拓等の「代わりにWebのコンテンツを取得する」機能。
最近ではSNSでURLを含む投稿を行った際、リンク先の文章やタイトル、サムネイル画像が表示されるプレビュー機能も該当する。
これらの機能を実装する際に、ネットワーク外部の宛先のみを想定し、ネットワーク内部を指定された場合の制御を行っていないケースをSSRF脆弱性と呼ぶ。
- 任意のURLに通信を送信できる脆弱性がある
本来通信を行っていなかった機能が、脆弱性により任意の宛先へ通信できてしまうケースが挙げられる。
悪用可能な脆弱性としてXML External Entity (XXE)脆弱性、パストラバーサル、OSコマンドインジェクション等が該当する。
これらの脆弱性があると、意図していない通信が発生することに注意が必要である。
○ 内部サーバ
- Webベースの管理コンソール/APIがあり、全てまたは一部がネットワークによるアクセス制御でしか防御されていない
アクセス制御がネットワークで担保されているという前提のため、利便性を重視してその他の防御策をとっていない場合に攻撃される危険がある。
理論的にはそういった性質を持つすべての管理コンソール/APIで実現可能だが、独自のシステムやAPIの場合、仕様を調査する必要があるため、有名な製品やサービスが狙われる。
攻撃に使われたサービスの例：AWSコンソール、Jenkins
サーバサイド・リクエストフォージェリの対策
○ 外部公開サーバ
- 任意のURLに通信を送信できる機能について検討する(SSRF脆弱性)
- 任意のURLである必要があるか、ホワイトリストでは実現できないか慎重に検討する。
- 任意のURLが必要であると判断した場合は、URLの入力規則を慎重に設計する。
- 任意のURLに通信を送信できる脆弱性の対策を行う
- 下記はSSRF攻撃以外にも使用されるリスクの高い脆弱性であるため、それぞれを確実に対策する必要がある。
- XML External Entity (XXE)脆弱性
- パストラバーサル
- OSコマンドインジェクション
- 下記はSSRF攻撃以外にも使用されるリスクの高い脆弱性であるため、それぞれを確実に対策する必要がある。
○ 内部サーバ
- ネットワークセグメントを慎重に設計する
「任意のURLに通信を送信できる機能」を実装したサーバは、ネットワークセグメントを分け内部ネットワークではなくDMZとして扱えないか検討する。
- ネットワークによるアクセス制御を過信しない
ネットワーク内には信頼できるコンピュータしか存在しないと考えずに、侵入/不正に送信された場合の施策を講ずる。
まとめ
今回はサーバサイド・リクエストフォージェリーについて解説した。SSRF脆弱性の対策としては入力値として与えられたURLを信用しないことに尽きる。
URLを安易に受け取る弊害についてはオープンリダイレクト等もあるため、アプリケーション仕様の策定時になるべく避けるようにした方が良いだろう。
イベント・セミナー
ニュース・キャンペーン
AppScanに
関するお問い合わせ
テクマトリックス株式会社
東京本社ネットワークセキュリティ事業部
第3営業部
セキュリティプロダクツ営業2課03-4405-7814
- メールでのお問い合わせ
- watchfire@techmatrix.co.jp