-
Notifications
You must be signed in to change notification settings - Fork 0
/
FUZZ_NOTES.txt
17 lines (11 loc) · 1.29 KB
/
FUZZ_NOTES.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
GET requests URI
- Within the URI, it seems like anything < 0x20 is filtered. And for >= 0x7f it is only certain. Everything else is allowed through.
list of integer values which cause a 400 error [1..32, 127, 192, 193, 245..255] (RFC 3629...e.g. they are enforcing UTF-8 charset)
- e.g. GET /whatever.cgi?lan\x81\x98 is just read as GET /whatever.cgi?lan
- same goes if we encode to %<INT>. e.g. GET /whatever.cgi?lan%129<ETC> is read just as GET /whatever.cgi?lan
- garbage is filtered out before the request is processed...e.g. ?<garbage>lan or ?lan<garbage> is identical response...garbage is filtered out then the request is processed
- So, we can get around any IDS-ey type sigs by doing GET /whatever.cgi?<garbage>l<garbage>a<garbage>n<garbage> etc.
- NOTE: THIS ONLY APPLIES TO THE ARGS TO THE RIGHT OF '?'....you can't insert garbage into the file name...only the parameters
- injecting chars doesn't change the HTTP status (200 OK), but it does affect the content that is delivered...so, 'whatever.cgi?;;lan;;' returns a 200 OK but no content. 'whatever.cgi?lan' returns a 200 and the full HTML content.
HTTP 431 seems to get triggered when params go over 128 chars...
The endpoint login_web_app.cgi seems to use 0x2e (period) as a delimiter (in addition to &) for POST data