(1) Get the request and response
(2) Refer request header: whether the parameter contains the session tokens("token", "once", "secret", "secid", "auth", "=tok", "=sig") to detect the token leakage.
(3) When the response MIME type is active content type, it may warn "external code inclusion":
"text/html", /* HTML */
"application/xhtml+xml", /* XHTML */
"application/java-vm", /* Java class */
"application/java-archive", /* Java JAR */
"application/x-shockwave-flash", /* Flash */
"video/flv", /* Flash */
"video/x-flv", /* Flash */
(4) If it detects the POST request, it may warn "Cross-domain POST requests"
(5) Now check the URL and response
- Is there any echoed query parameter in response body?
- Is there any echoed query parameter in response headers?
- check whether the URL contains the authentication fields? "login","user", "sess","account","pass"
- re-send without cookie to double check whether it is a request require authentication
- Sniff the char set in response body. The valid charset is:
"iso8859-1", /* Valid Western */
"iso-8859-1", /* Invalid but recognized */
"iso8859-2", /* Valid European */
"iso-8859-2", /* Invalid but recognized */
"iso8859-15", /* ISO-8859-1, new and improved */
"iso-8859-15", /* ISO-8859-1, new and improved */
"windows-1252", /* Microsoft's Western */
"windows-1250", /* Microsoft's European */
"us-ascii", /* Old school but generally safe */
WARNING: Please note that "harmless" misspellings such as
'utf8' or 'utf_8' are *not* harmless, and may trigger utf-7
XSSes. Do not add these to the list unless thoroughly
validated.
- Try_replay_xsrf: set all the session tokens in the request to clobber value, and then send it again to the server, then compare the md5 of the result.
- The header based check: for example, authentication header but not 40x response.
- HTTP redirect: detect 302 response with location header: is the host name in the request query parameter or payload?
- Check the redirect in payload: HTTP-EQUIV=\"Refresh\"
- Handle Content-Type: multipart/form-data ??
- If the response and request cookies are the same, Cookie issuer with no XSRF protection
- POST requests that do not require authentication are interesting
- Multiple "Content-Type or Content-Disposition" headers
- Misstated Content-Length: pay load greater than the content-length header
- Check cross domain POST request: the request host and refer host is different.
- Cacheable SetCookie: Check if the web page can be cached and with the cookie/auth
- Missing charsets and typos lead to UTF-7 cross-site scripting.
- content sniffing and content-type mismatch
- Echoed markup in a query is bad.
- File path in query parameters: Non-echoed paths in query are often bad
- Java method names in a query are bad.
- Javascript code in a query is bad; ignore alert(...) though, as this is almost always a sign of manual XSS testing, not a legitimate functionality.
- SQL statement in a query is bad.
- Check for OGNL-style parameter names.
- Check for what looks like JSON with inline HTML (we skip standalone scripts,as they often contain static HTML to be rendered). We do some basic quotestate tracking not to get confused by regular arithmetic. No commenttracking, but that shouldn't break easily.
- Response with directory index: "\>[To Parent Directory]\<" "\
- javascript .write(, .writeln(, .innerHtml, .outerHtml, document.referrer, document.domain
Examples how will it work:
a). Somebody created a link and you clicked out:
http://bank.com/logon?error=
* echo response detected.
When ratproxy saw this request, then it will check the query parameters in the request header against response payload
* different domain name/ip/hostname in query parameter are found
b). after you fill in your user name and password and click it
* If the bank had a refer header, so a cross-domain POST is detected.
* POST may contain the authentication token or cookie?
*
No comments:
Post a Comment