まとめ — サーバの内側を、締める

SSRFとデシリアライズを畳みます。「サーバが代理で動く」処理を疑う視点を持って、ビジネスロジックと競合状態のコースへ進みます。

第4章 / 全5章目安約3分この章のゴール: サーバサイドの穴を畳み、次のコースへの道筋を持つ

利用者の入力を直接扱う場所ではなく、サーバが代わりに動く場所に潜む穴——SSRFとデシリアライズ——を、自作の構成で一巡しました。

サーバサイドの深い穴・早見表

穴	サーバが何を代行するか	直し
SSRF	指定されたURLを、代わりに取りに行く	許可リスト + 実IPでの内部帯遮断
安全でないデシリアライズ	届いたデータを、代わりに元の形へ復元する	JSON.parse(データとしてのみ解釈)+ スキーマ検証

2つに共通する視点——「この処理は、サーバが利用者の代わりに何かをしていないか?」を、コードを読むときにいつも持つ。URL を取得する・ファイルを開く・データを復元する・外部コマンドを呼ぶ(sec-injection のコマンドインジェクションもこの仲間でした)。サーバが持つ権限を、利用者の入力がどこまで動かせてしまうかを疑うのが、この領域の診断の芯です。

一貫する原則、いくたびも

SSRF の許可リスト、デシリアライズの JSON.parse——どちらも、これまでと同じ「信じるものを明示し、それ以外は拒む」姿勢でした。そしてブラックリストの弱さ(表記の揺れで迂回される)も、パストラバーサルやCORSと同じ形で現れました。この一つの原則が、ほとんどの穴を貫いています。

次の道 — ビジネスロジックと競合状態

次は「ビジネスロジックと競合状態」です。ここまでの穴は「入力がコードになる」「サーバの立ち位置が悪用される」という、比較的機械的に見つけられるパターンでした。次のコースは、もっとそのアプリ固有の“当たり前”が崩れる種類の穴——数量がマイナスになる、同時に処理されて在庫が二重に確保される——を扱います。ツールでは見えにくい、認可の穴(sec-authz)と並ぶ、人の目が要る領域です。

このコースの実習相手も、すべて自分の 127.0.0.1 の自作構成でした(法と倫理)。SSRF はとくに、実在サービスのクラウド環境で深刻な被害を生んできた穴です。仕組みが分かった今だからこそ——試すのは、自分の許可環境の中だけ。

お疲れさまでした。サーバの「内側」で何が起きているか、あなたにはもう見えています。

こうなっていればOK

SSRFとデシリアライズの原因と直しを、それぞれ一言で言える
「サーバが代理で動く」処理を疑う視点を持てた
次のビジネスロジックのコースへの道筋を持てた

この章で卒業です。

この章はまだ完了していません。