file-upload-and-ssrf について
アップロードファイル、ユーザー指定URL、シリアライズ入力をサーバーが処理する際のセキュリティテストスキルです。許可されたテストで危険な処理箇所を特定し、安全に影響を確認して証拠と到達可能性を記録します。
主な機能
- 01アップロード検証不備の確認
- 02URL取得処理のSSRFテスト
- 03安全でないデシリアライズ箇所の特定
- 04安全な確認方法の提示
- 05証拠と到達可能な影響の記録
活用シーン
- 01許可された環境でのアップロード処理評価
- 02URLプレビューやインポート機能のSSRFテスト
- 03信頼できないシリアライズ入力の実行リスク調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/file-upload-and-ssrfを入力して読み込まれたか確認します。
同梱ファイルreferences/upload-ssrf-recipes.md
詳細
ファイルアップロード、SSRF、デシリアライズ（検出／エクスプロイト — サーバーの入力処理）
概要
これらは、RCE またはクラウド全体の侵害につながることが多い、影響の大きい 3 種類の問題です。これまで参照資料のどこにも扱われていませんでした。信頼できない ファイル、信頼できない URL、信頼できない シリアライズ済みオブジェクトです。いずれも「サーバーが攻撃者の提供したデータを処理する」ことに起因します。
基本原則： サーバーが攻撃者のデータを 取得、保存して配信、または 再構築 する場所では、どこを参照させられるか、あるいは何に変えられるかを確認してください。
該当する場合／対象外の場合
- 該当する場合： アプリが ファイルをアップロード できる、ユーザー指定の URL を取得 する、または入力を デシリアライズ する場合は、3 項目をそれぞれ個別にテストします。
- 対象外の場合： 該当する機能がない場合、その項目は該当なしです（例：アップロード機能がなければアップロードのセクションは省略しますが、SSRF／デシリアライズ機能があれば引き続きテストします）。
- 該当しない場合： 3 項目のうち存在しないものを報告し、存在するものだけをテストします。
⚠️ 認可
自身が所有する、または許可を得た非本番環境で実施してください。SSRF によって実際の内部インフラやクラウド認証情報に到達する可能性があるため、対象は自身の環境に限定し、無害なカナリアを使用して、スコープ外へ侵入しないでください。
ファイルアップロード
| 確認項目 | テスト |
|---|---|
| 種類／拡張子のバイパス | shell.php.jpg、二重拡張子、ヌルバイト、大文字・小文字、.phtml／.svg／.htaccess |
| Content-Type の偽装 | 実際の画像バイト列＋スクリプト、不一致の Content-Type ヘッダー |
| ポリグロット | 画像 かつ スクリプトとして有効なファイル（例：GIF／PHP） |
| パストラバーサル | ファイル名 ../../var/www/shell.php を指定し、保存先を制御できるか確認 |
| 実行可能な場所 | Web 経由で配信され、実行可能なディレクトリに保存されるか |
| パーサー攻撃 | 悪意のある SVG（XXE／XSS）、Office／ZIP（zip-slip、XXE）、画像ライブラリの CVE |
| 制限 | サイズ／レート制限、展開爆弾 |
致命的な条件は アップロード → 到達可能な実行パス → 実行 です。ファイルが Web ルート外にランダムな名前で保存され、実行不可であれば、ほとんどのアップロードの問題は影響が大幅に抑えられます。
SSRF
- シンク： URL プレビュー／展開、Webhook、URL からのインポート、PDF／スクリーンショット／画像の取得、SSO メタデータ、file:// ハンドラー、サーバー側 HTTP クライアント。
- 実証する対象（無害な方法で）： 自身のコラボレーター／OOB ホスト、次に
127.0.0.1／内部リソース、続いてクラウドのメタデータhttp://169.254.169.254/latest/meta-data/（AWS）、metadata.google.internal（GCP）。 - テストするバイパス： 別形式の IP 表記、
[::1]、DNS リバインディング、リダイレクト、@を使ったトリック、許可リストの解析不備。 - SSRF→クラウドメタデータ→IAM 認証情報は、実証する価値の高い 攻撃チェーン です（
vulnerability-chainingを参照）。
安全でないデシリアライズ
- シンク： 信頼できない入力に対する
pickle.loads、yaml.load、Java のreadObject、PHP のunserialize、.NET のBinaryFormatter、Node のnode-serialize。 - 検出方法：Cookie／パラメーター／本文に含まれるシリアライズ済みデータを確認します。改ざんによってサーバーの動作が変わるかをテストします。
- 無害なガジェット（OOB ping）で確認します。破壊的なガジェットチェーンは実行しないでください。
ペイロードと安全な確認方法については references/upload-ssrf-recipes.md を参照してください。
出力
検出事項ごとに、シンク、ペイロード、証拠（ファイルの実行場所／OOB のヒット／オブジェクトの再構築）、到達可能な影響（RCE、内部アクセス、クラウド認証情報）を記載します。通常、深刻度は高～重大です。
引き継ぎ
vulnerability-chaining では、侵入の足掛かり／ピボットとして使われることがよくあります。active-pentest で再現し、security-hardening で修正します（Web ルート外に保存＋コンテンツを検証＋ランダムな名前を使用、URL 許可リスト＋内部 IP 範囲をブロック＋IMDSv2、安全なデシリアライズ形式）。
よくある間違い
- クライアント側でファイル拡張子だけを確認する — サーバー側でコンテンツを検証してください。
- リダイレクト、DNS リバインディング、IP 表記のバイパスをテストせずに「SSRF なし」と判断する。
- 実際の内部インフラや本番環境に対して SSRF をテストする — 自身の環境内にとどめてください。
- デシリアライズを理論上の問題として扱う — RCE に直結する一般的な経路です。