hunt-exceptional-conditions

1# HUNT-EXCEPTIONAL-CONDITIONS — Verbose Errors / Fail-Open (A10:2025)
2 
3## What actually pays
4 
5Well-built apps catch errors and return a clean, generic message. A broken app,
6when handed input it didn't expect, throws an unhandled exception and renders a
7**developer error page** straight to the client — leaking the stack trace, the
8ORM/query internals, server-side file paths, and framework/library versions.
9That disclosure is the finding (and it arms SQLi/RCE/path attacks next).
10 
11## Recon
12 
13Any endpoint that parses input is a candidate; the richest are:
14 
15```
16JSON APIs that expect typed fields:  POST /api/* with {numbers, ids, enums}
17Endpoints with numeric/id path or query params:  /item/{id}, ?page=, ?quantity=
18Search / filter / sort params
19File or content-type sensitive uploads
20```
21 
22## Attack — send what the code didn't anticipate
23 
24Take a known-good request and break ONE assumption at a time:
25 
26- **Wrong type:** a field the app expects to be a number/string is sent as an
27  array or object — `{"rating":"x","comment":[1,2,3]}`, `{"quantity":{}}`.
28- **Malformed body:** truncated/!invalid JSON, an unterminated string, a stray
29  brace, a wrong/missing Content-Type.
30- **Boundary/oversized:** a very long string, a huge/negative/overflow number.
31- **Null byte / control chars** embedded in a value.
32 
33```
34POST /api/Feedbacks   {"rating":"notanumber","comment":[1,2,3]}
35GET  /item/' OR /item/%00   (also exercises the error path)
36```
37…