hunt-exceptional-conditions

HUNT-EXCEPTIONAL-CONDITIONS — 詳細なエラー／フェイルオープン（A10:2025）

実際に有効なポイント

適切に構築されたアプリはエラーを捕捉し、簡潔で一般的なメッセージを返します。壊れたアプリは、想定外の入力を受け取ると、未処理の例外をスローし、開発者向けエラーページをそのままクライアントに表示します。これにより、スタックトレース、ORM／クエリの内部情報、サーバー側のファイルパス、フレームワーク／ライブラリのバージョンが漏えいします。この情報開示が検出対象です（そして、次の SQLi／RCE／パストラバーサル攻撃の手掛かりになります）。

偵察

入力を解析するエンドポイントはどれも候補ですが、特に有望なのは次のとおりです。

JSON APIs that expect typed fields:  POST /api/* with {numbers, ids, enums}
Endpoints with numeric/id path or query params:  /item/{id}, ?page=, ?quantity=
Search / filter / sort params
File or content-type sensitive uploads

攻撃 — コードが想定していない値を送信する

正常なリクエストを基に、前提を一度に 1 つだけ崩します。

• 型の不一致： アプリが数値／文字列として想定するフィールドに、配列またはオブジェクトを送信します — {"rating":"x","comment":[1,2,3]}、{"quantity":{}}。
• 不正なボディ： 途中で切れた／無効な JSON、閉じられていない文字列、余分な中括弧、誤った、または欠落した Content-Type。
• 境界値／過大な値： 非常に長い文字列、巨大な数値／負の数値／オーバーフローする数値。
• 値に埋め込まれたヌルバイト／制御文字。

POST /api/Feedbacks   {"rating":"notanumber","comment":[1,2,3]}
GET  /item/' OR /item/%00   (also exercises the error path)

ステータスだけでなく、レスポンスボディを確認してください。500（または 200／400）でも、ボディにスタックトレースやフレームワークのエラーページが含まれていれば、その兆候です。

漏えいと見なされるもの（成功の兆候）

レスポンスボディに、複数のフレームワークで見られるエラー情報開示の特徴が含まれている場合、検出が確定します。

• Node/Express + Sequelize： SequelizeDatabaseError、node_modules/sequelize、内部パスを含む JS スタック。
• PHP： <b>Warning</b> ... /var/www/.../file.php on line N。
• Python： Traceback (most recent call last)、werkzeug.exceptions。
• Java： at com.app.Foo(Foo.java:42) というスタックフレーム。
• .NET： Server Error in '/' Application、[System.XxxException: ...] を含む YSOD。

内部情報を含まない、クリーンな JSON エラー（{"error":"Invalid input"}）は検出対象ではありません — これは正しい処理です。内部構造の開示が検出対象です。

検証時の注意事項

• 漏えいした具体的な情報（パス、ORM クラス、バージョン、スタックフレーム）を正確に記録してください — それが証拠です。「500 が返された」だけでは情報開示とは言えません。
• 漏えいした情報によって次に可能になることを記録してください（例：SQL エラーの開示 → hunt-sqli、絶対パスの開示 → hunt-lfi）。