リクエストフォージェリを再考 – リクエストのインジェクションと考える

(更新日: 2015/08/07)

リクエストフォージェリを再考してみたいと思います。リクエストフォージェリには

  • SSRF(サーバーサイドリクエストフォージェリ)
  • CSRF(クロスサイトリクエストフォージェリ)
  • XXE(XMLエクスターナルエンティティ)

などがあります。これらは「リクエスト」を「偽装」(フォージェリ)する攻撃です。名前からは直感的にどのような攻撃なのかよく解らないですが、「攻撃リクエストのインジェクション」と考えると解りやすいと思います。

リクエストフォージェリとは?

リクエストフォージェリとは偽装したリクエストを正当なリクエストとして処理してしまう問題です。この問題は古いUNIX系システムで利用されていたリモートシェル(rコマンドと呼ばれていた)を利用した場合に発生することが広く認識されていました。

スライド1

セキュリティ標準的には「真正性」(Authenticity – リクエストが本当にリクエストを送信したエンティティが送信したモノであることを保証する性質)の問題になります。

この種類のサーバーが持つアクセス権を利用して、不正な処理を行わせる攻撃手法はSSRF(サーバーサイドリクエストフォージェリ)と呼ばれ、古くから知られていました。

 

CSRF(クロスサイトリクエストフォージェリ)

CSRFも仕組みはクラシックなリクエストフォージェリと変わりません。

スライド2

 

XXE(XML eXternal Entity)など

XXEもCSRFと仕組みは同じです。詳細は以下のスライドを参照してください。

 

リクエストフォージェリの本質

リクエストフォージェリは本質的に「リクエストのインジェクション」と考えると、全てのリクエストフォージェリが理解り易くなります。

スライド3

CSRFやXXE、SSRFなど名前だけでは解りづらいリクエストフォージェリですが

  • 第三者が中継システムを経由し、中継システムの権限で攻撃コマンドを挿入(インジェクション)する攻撃

と理解すると解りやすいのではないでしょうか?

リクエストフォージェリを防ぐには、「リクエストが何等かの方法で、権限を持っているエンティティ(ユーザー、プロセスやシステム)経由で不正に実行されるケースがないか?」を考えればリスクを識別し、対策できることになります。

 

まとめ

個別の脆弱性名を基礎知識として知っておく必要はありますが、リクエストフォージェリは

  • 第三者が中継システムを経由し、中継システムの権限で攻撃コマンドを挿入(インジェクション)する攻撃

と理解すれば同じパターンとして覚えられます。防御策の考え方、

  • リクエストが何等かの方法で、権限を持っているエンティティ(ユーザー、プロセスやシステム)経由で不正に実行されるケースがないか?

は中継システムがない直接インジェクションする攻撃パターンも考えるように範囲を広げると、「再生攻撃」などへも対応できるようになります。さらに範囲を広げてレスポンスのインジェクションも考慮するとさらに対応範囲が広がります。

リクエスト・レスポンスが直接・間接にインジェクションされるケースはあるか?

これを考えると個別の脆弱性名が付けられていない認証プロセスなどの脆弱性も自分で考えれるようになります。

時々見つかる発見しづらいWebアプリの脆弱性に「アプリ内のリダイレクト」(HTTPリダイレクトではなく、アプリ内部でリクエストのリダイレクトを行うようなコード)による不正実行脆弱性があります。リクエストやレスポンスデータがどこからやってくるのか?つまり入力がどのような入力か?をよく考えると防ぐことができます。これも

リクエスト・レスポンスが直接・間接にインジェクションされるケースはあるか?

と考える応用の一つです。

 

Comments

comments

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です