実演動画あり！サーバサイド・リクエスト・フォージェリ（SSRF）とは？

サーバーサイド・リクエスト・フォージェリ（SSRF）とは？

近年の多くのWebサイトはバックエンドの内部システムと連携してサービスを提供しています。しかし、このような連携を外部入力をもとにアプリケーションロジック内で実装していた場合に、この連携先を変えて意図した処理とは異なる処理をサーバーサイドに実行させることができてしまうことがあります。

このようなサーバーサイドの連携内容を変更して意図しない処理を実行させてしまう問題をサーバーサイド・リクエスト・フォージェリ（SSRF）脆弱性と呼び、この問題を狙った攻撃をサーバーサイド・リクエスト・フォージェリ（SSRF）攻撃と言います。

特に昨今ではクラウドサービスを利用して様々なサーバーと連携してWebサービスを提供する機会が増えているため、このサーバーサイド・リクエスト・フォージェリ（SSRF）対策を怠って混入させてしまうと重大なインシデントを招く恐れがありますので、注意が必要と言えます。

なお、サーバーサイド・リクエスト・フォージェリ（SSRF）は、能動的攻撃としても受動的攻撃としても成立しますが、過去に起きた被害事例から能動的攻撃のターゲットとなった場合に、より被害が大きくなる傾向があります。

サーバーサイド・リクエスト・フォージェリ（SSRF）攻撃の仕組み

以下は、能動的攻撃に分類されるサーバーサイド・リクエスト・フォージェリ（SSRF）攻撃の例となります。

サーバーサイド・リクエスト・フォージェリ（SSRF）攻撃の例

1. 攻撃者は細工を施したHTTPリクエストを送信する
2. 直接アクセスできないサーバーに対して処理依頼が発行される
3. 本来とは異なるデータを含んだ処理結果が応答される

上記は、本来、非公開となっているため直接アクセスできないデータベースサーバーに対してサーバーサイド・リクエスト・フォージェリ（SSRF）脆弱性を悪用してWebアプリケーションを通してアクセスして、データを奪取している例となります。

被害事例

以下はアメリカで起こったサーバーサイド・リクエスト・フォージェリ（SSRF）攻撃による被害例です。

Capital One

2019年7月に米金融大手のCapital One社で起きた不正アクセス事件により1億人以上の個人情報が漏洩しました。発生原因の詳細は明らかにされていませんが、サーバーサイド・リクエスト・フォージェリ（SSRF）攻撃によって引き起こされたとのことです。なお、漏洩した個人情報にはクレジットカード番号や社会保障番号など被害者の生活に直接影響を与えうる多くの情報が含まれていました。

脆弱性の解説動画

サーバーサイド・リクエスト・フォージェリ（SSRF）が起こる原因

様々なケースでおき得るサーバーサイド・リクエストフォージェリ（SSRF）脆弱性ですが、多くの場合、インターネットに直接接続していない非公開領域であることから、ネットワーク制御やアクセス制限が十分ではないことが原因で発生します。

以下は、サーバーサイド・リクエストフォージェリ（SSRF）脆弱性が混入しやすい例となります。

ローカルアドレスに対するアクセス制限の回避

一般ユーザーが利用するWebアプリケーションと管理者が利用するWebアプリケーションが同一サーバー上に構築されているケースでは、管理サイトを非公開にしていてもローカルアドレスなどを指定することでバイパスできてしまうことがあります。

ホワイトリスト形式のチェック不備

予め連携先のドメインなどが決まっておりホワイトリスト形式でチェックを行なっている場合、完全一致でのチェックを行なっていないと、サブドメイン指定や＠「アットマーク」や＃「フラグメント」などのURL分割を悪用した攻撃によってチェック機能を回避できてしまうことがあります。

プロキシサーバーの設定不備

負荷分散やシステムの構成上、フロントエンドにプロキシサーバーを配置することはよくありますが、この時にプロキシサーバーの利用範囲を誤ってしまうとインターネット側からプロキシサーバーを経由して自由に内部ネットワークに侵入することができてしまうケースがあります。

サーバーサイド・リクエスト・フォージェリ（SSRF）攻撃への対策手法

システム構成によって必要な対策が異なるため、実施する場合は、以下の基本対策を元に必要な対策を選んで実施します。

基本対策1（ネットワーク保護）

内部ネットワーク間である場合、ネットワークの制限を設けていない、あるいは設定自体が緩いケースが多いため、しっかりとファイアウォール（WF）機能を利用して必要のない通信を遮断します。このように通信自体に制限を設けることでサーバーサイド・リクエスト・フォージェリ攻撃を防止することができます。

基本対策2（サーバー設定）

原則、1台のサーバーには1つの役割に押さえて運用します。前述したように異なる目的のWebアプリケーションを動作させるといった運用は避けることが望ましいと言えます。またプロキシサーバーとして運用する場合は、予め決められた通信相手以外へのリクエストは遮断するなど、用途に合わせてサーバー設定をチューニングします。また認証情報（クレデンシャル）を用いた通信を行う場合は、許容する操作やパーミッション情報を絞り不要な権限を与えないようにすることも重要です。

基本対策3（アプリケーションロジック）

Webアプリケーションの処理において連携先を振り分ける場合には、可能であればホワイトリスト形式で完全一致した場合のみ処理を実行するようにします。前述したように前方一致や後方一致、あいまい検索などでのチェックは抜けや漏れが発生しやすいため、運用状況と照らし合わせた上で可能な限り、このような実装は避けて、完全一致でのチェックを行うことが望ましいと言えます。

まずは手軽にツールで脆弱性診断

上述の対策手法が重要となる一方で、脆弱性が混入されていないかを検知する事も重要となります。

脆弱性診断とは何かについて詳しく知りたい⽅は脆弱性診断とは(エンジニア向け)と脆弱性診断とは(⾮エンジニア向け)もぜひご参照ください。

脆弱性検知やセキュリティレベルを強化したい企業様はぜひ弊社の脆弱性診断ツール「Securify Scan」を活用ください。

無償でのトライアル実施も行っておりますので、お気軽にお問い合わせください。