【SSRF・LFI編】サーバを内側から覗かせる手口と守り方｜CTF思考フレームワーク #11

こんにちは、アンペンです！

前回は、ブラウザ側の境界線であるSOPと、その例外を作るCORSの安全な使い方を学びました。

今回は、サーバー自身が外向き/内向きにリクエストを出してしまう問題、SSRFとLFIを扱います。「サーバを内側から覗かせる」攻撃と、その断ち方を見ていきましょう。

サーバが勝手に内部に通信するって、どういう仕組みで起きるの？

『URLを指定するとそのページを取りに行く』機能や、『パスを指定するとそのファイルを読む』機能を、攻撃者が内部向けに使わせるから起きるんだ。

SSRF、LFI——アルファベットが並ぶと急に身構えてしまいますよね。でも今日の話の芯は、たったひと言で言えます。『サーバに、代わりに取りに行かせる』。これだけです。本来は便利なはずの“お使い機能”を、攻撃者が悪用して、サーバ自身に内部の秘密を持ってこさせる。今日はその仕組みを、会社の受付係への“資料取り依頼”にたとえて、ゆっくりほどいていきます。

SSRFとLFIは「便利な機能」が裏返ったもの

SSRF(サーバサイドリクエストフォージェリ)は、ユーザが指定したURLをサーバが取りに行く機能(プレビュー、Webhookなど)で発生します。LFI(ローカルファイルインクルージョン)は、ユーザが指定したパスをサーバがファイルとして読み込む機能で発生します。

どちらも「便利な取得機能」が前提です。サーバ側で行き先を制限していないと、攻撃者は内部のIPアドレスや、本来見えないはずのファイルを指定して、サーバに代わりに読みに行かせます。

なぜサーバに取りに行かせると、そんなに強力なのでしょう。理由は『サーバは内側にいる住人』だからです。外部の攻撃者は、社外から内部ネットワークには入れません。でもサーバは、内部の管理画面にも、設定ファイルにも、堂々とアクセスできる立場にいます。その“内側の住人”を操って使い走りにできれば、外からは絶対に届かない場所の情報まで引き出せてしまう。SSRFが怖いのは、まさにこの“立場の乗っ取り”だからなんです。

まず『便利な取得機能』とは何か、具体例で見てみましょう。たとえば「URLを貼ると、そのページのプレビュー画像を表示する」機能。あるいは「画像のURLを入れると、それをアイコンに設定する」機能。これらはどれも、利用者が指定したアドレスへ“サーバが代わりにアクセスしに行く”仕組みです。ふだんは超便利。でも、この“行き先”を攻撃者が自由に書き換えられたら——というのが、今日の出発点です。

図解：SSRFとLFIの動き

通常の使い方と、攻撃者が内部宛に書き換えた場合を比べると、サーバが何を取りに行くかが大きく変わります。

このメタデータエンドポイント、SSRFの世界では“最後の大物”とも言える存在です。クラウド上のサーバは、 169.254.169.254 という特別な内部アドレスに聞くと、自分自身の鍵束（一時的な認証情報）を教えてもらえる仕組みになっています。これは本来、サーバ自身のための便利機能。でもSSRFでここを叩かれると、攻撃者はその鍵束ごと手に入れて、クラウド上の他の資産にまで手を伸ばせてしまう。だから「内部の特別アドレスには行かせない」ことが、何より重要になります。

SSRF/LFIの典型パターン

SSRF/LFIの狙われ方は、大きく3つです。『外から見えない内部サービスを覗く』『クラウドの鍵束（メタデータ）を奪う』『サーバ上の設定ファイルを読む』。前の2つがSSRF、最後がLFI寄りですが、根っこは同じ。“利用者が行き先を指定できる”という一点から、すべてが生まれます。

代表的な狙われ方

• SSRFで内部サービスへアクセス：外部からは見えない内部APIや管理画面をサーバ経由で叩く
• SSRFでクラウドメタデータを取得：クラウドの一時クレデンシャルを奪い、権限昇格やデータ持ち出しにつなげる
• LFIで設定ファイルを読み取る： /etc/passwd やアプリ設定、ログファイルからシステム情報や認証情報を抜く

これらはURLやパスを利用者入力で受け取っている部分が共通点です。プレビュー機能・Webhook送信・ダウンローダー・テンプレ読み込みなど、対象になる機能は意外と多くあります。

ここで『うちのサイトにそんな機能あったかな？』と思った人へ。実は対象になる機能は、想像よりずっと多いんです。URLプレビュー、Webアバター取得、Webhook送信、PDF生成、ファイルダウンローダー、テンプレート読み込み……「利用者が入れた文字をもとに、サーバが何かを取りに行く」ものは、すべて候補。だからまず大事なのは、自分のサービスの中で“行き先を利用者が決められる場所”を棚卸しすることなんです。

では、自分のラボでそういう機能を探してみましょう。実際に内部IPを叩く必要はありません。「この機能、行き先を私が指定できてしまうな」と気づくだけで十分です。本物のサービスでメタデータURLや内部IPを試すのは、たとえ確認目的でも厳禁。安全な環境で“入力が行き先になっている経路”を見つける——それが今日の練習です。

CTFでやってみよう：URLやパスの取り扱いを観察する

守りの話に入る前に、一つだけ注意点を。『入力をチェックすればいい』と思いがちですが、これが意外と抜けやすいんです。

『内部IPっぽい文字列を弾く』だけじゃダメなの？

それだけだと、すり抜けられることがあるんだ。たとえば一見ふつうのドメインでも、その名前が内部IPに解決されるよう仕込まれていたり、いったん許可されたあと別の場所へ転送（リダイレクト）されたり。文字の見た目だけ見ても“最終的にどこへ届くか”は分からない。だから守りは、名前ではなく『解決された実際のIP』で判断して、ネットワーク側でも内部宛をブロックする——二重三重に固めるのが正解だよ。

守る側なら、「行き先を絞る」を徹底しよう

SSRF/LFIの守りの核は、「利用者入力からURLやパスを組み立てるとき、行き先を絞る」ことです。バリデーションだけでは抜けやすいため、ネットワーク・OS・アプリの3層で塞ぐのが理想です。

『便利な取得機能』はそれだけで危ない、と思っていいんだね。

『行き先を利用者が決められる機能』は、SSRF/LFIの可能性をまず疑うのが正解だよ。

ここまでをひと言で言うと、SSRF/LFIの本質は『行き先を利用者に決めさせてしまった』ことです。だからいちばん強い守りは、そもそも“行き先を選ばせない”設計。どうしても必要なら、行ける場所をホワイトリストで決め打ちし、内部だけは何があっても通さない。自由度を捨てる勇気が、ここでは安全に直結します。

まとめ：行き先を絞れば「内側を覗かせる」を断てる

今日の持ち帰りは『サーバのお使いには、必ず行き先リストを持たせる』です。便利な取得機能は、放っておくと“なんでも持ってくる使い走り”になってしまいます。行けるのはここだけ、内部には絶対行かない——その地図をサーバに渡しておけば、内側を覗かせる攻撃はぐっと防ぎやすくなります。

次回は、複数の処理が同じデータを取り合うときに起きるレースコンディションを扱います。タイミングの隙間を突く攻撃と、その守り方を見ていきましょう。

次に読みたい記事

参考資料