AIで403 Forbiddenを突破する方法

Hello there, ('ω')ノ

背景：なぜヘッダーで403が回避できるのか

多くのウェブアプリやリバースプロキシ（例：Nginx、Cloudflareなど）は、リクエストヘッダーを参照してアクセス制御やルーティングを行っています。管理用のエンドポイントや内部APIが特定のヘッダーを期待している場合、そのヘッダーを付与することで該当リソースにアクセスできることがあります。これを利用するのが「ヘッダーによるバイパス」です。

AIの役割（何を期待できるか）

AI（大規模言語モデル）は、人間が思いつきにくい「レアなヘッダー名」や、過去の事例に基づいた有力候補を短時間で列挙できます。手作業だと見落としやすいヘッダー（例：X-Original-URLやX-Hostなど）を提案してくれるため、効率的な試行が可能になります。

実践：AIに投げるシンプルなプロンプト例

Prompt（例）:
Give me a list of HTTP headers that can help bypass 403 Forbidden responses for a target behind Cloudflare and Nginx.

AIはこのような入力から候補リストを返します（例：下記）。

X-Forwarded-For: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Host: target.com
X-Original-URL: /api/admin-panel/config

※上は例示です。実際の攻撃には使わないでください。検証は必ず対象の許可を得た環境で行ってください。

自動で試す：ffufを使ったヘッダーファジング

AIで生成したヘッダーを ai_headers.txt に保存し、ffufでヘッダー位置をFUZZしてレスポンスコードを確認する方法。

ffuf -w ai_headers.txt -u http://target.com/admin -H "FUZZ" -mc 200

このコマンドのポイント：

-w ai_headers.txt：試行するヘッダー候補を行ごとに書いたファイルを指定
-u：ターゲットURL
-H "FUZZ"：ヘッダーの値をFUZZ（ffufが行にある値で置き換える）
-mc 200：HTTP 200（成功）を検出対象とする（目的に応じて変更）

初心者向けの安全で効率的なワークフロー（ステップ）

スコープ確認 バウンティポリシーやテスト許可を明確にする。許可がない範囲は絶対に触らない。
パッシブ情報収集 CTログ、Wayback、公開リポジトリなどで内部的なURLや端末情報を探す。
AIで候補生成 ヘッダー名、推奨するヘッダー値、注意点を出してもらう。
小さなバッチで検証 まずは手で数個だけ試し、挙動を観察する（ログやエラーメッセージを読む）。
自動化（ファジング） 信頼できる候補セットでffufなどを用いて規模を広げる。
結果の評価と優先度付け 発見したエンドポイントをインパクトとリスクでランク付けする。
報告（バウンティに提出する場合） 再現手順、証拠（リクエスト/レスポンス）、影響範囲、推奨対策を明記する。

チェックリスト（必ず守ること）

許可（スコープ）があるか？ ✔
パッシブ優先で実施しているか？ ✔
テストで見つけた結果を第三者に公開していないか？ ✔
発見は適切なチャンネル（報告フォーム）で提出しているか？ ✔

防御側の観点：開発者／運用者が取るべき対策

不要な内部向けヘッダーを外部に露出させない。
ヘッダーによるルーティングや認可に過度に依存しない（複数要素を組み合わせる）。
信頼できないヘッダー値は検証・正規化する。（元記事はこうした手法の逆を突く例と、その検出方法を示唆しています。）

注意（重要）

この記事は教育目的での解説です。許可のないテストは違法行為となる可能性が高く、実施しないでください。実務で試す場合は、必ず明確な書面での許可を得て、ルールに従って行ってください。

まとめ

AIはヘッダー候補の発見や試行設計で強力な補助になりますが、使うのはあくまで補助的手段です。最終的な判断・安全性の担保は人間が行いましょう。
小さく始めて段階的に自動化することで、効率よく発見に結びつけられます。
見つけた問題は適切に報告し、防御強化に役立ててください。

Best regards, (^^ゞ

Shikata Ga Nai

Private? There is no such things.