Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Burp Scanner does not recognize Open Redirect

Benjamin | Last updated: Sep 08, 2016 11:33AM UTC

Burp Scanner does not recognize Open Redirect: When checking the raw scanner requests/responses with Logger++ I spotted the following Open Redirect situation that was not recognized/reported by the scanner: POST-parameter xxx can be used to set redirect target Website replies with "HTTP/1.1 302 Found" with user-controlled Location header with value of parameter xxx The following might aid in identifying the bug: Checked with Burp Suite Professional version 1.7.04 and 1.7.05 Open Redirect checks are activated in scanner options The server answered with HTTP response code 302 and not 301 Tested without collaborator and with private collaborator server (but in internal network without internet access) Three checks led to successful user-defined redirect 302: 1) Burp collaborator URL in vulnerable parameter 2) value of /etc/passwd in vulnerable parameter (path traversal checks) 3) value of /etc/passwdX in vulnerable parameter (path traversal checks) Thank you, kind regards Ben

Liam, PortSwigger Agent | Last updated: Sep 08, 2016 12:17PM UTC

Hi Ben Thanks for your message. Burp Suite should find all Open Redirection Vulnerabilities. Would it be possible to provide us with access to the application so we can better assess what is happening? Failing that, a redacted version of the request / response?

Burp User | Last updated: Sep 09, 2016 09:45AM UTC

Hi Liam, please find the redacted request/response below. Burp did not find the open redirect even though it is text book style. regards Ben POST /redacted/path/login.php HTTP/1.1 Host: www.redacted.com User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br DNT: 1 Referer: https://www.redacted.com/redacted/path/login.php Cookie: JSESSIONID=DEADBEEF6B690E7B865A46CDDEADBEEF.aa_bbb_1_cc_0 Connection: close Upgrade-Insecure-Requests: 1 Content-Type: application/x-www-form-urlencoded Content-Length: 142 AAAAA=ISO-8859-1&BBBBBBBB=US-EN&SOME=aaa&THING=bbb&location=https://www.controllable.com&abfoo=&abbar=&abfoobar=&notrelevant= HTTP/1.1 302 Found Date: Thu, 08 Sep 2016 10:31:15 GMT Server: Apache Cache-Control: no-store Location: https://www.controllable.com Content-Length: 276 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://www.controllable.com/">here</a>.</p> <hr> <address>Apache Server at www.redacted.com Port 443</address> </body></html>

PortSwigger Agent | Last updated: Sep 09, 2016 09:46AM UTC

Thanks for the further detail. From the example given, it seems that Burp should report this issue. It certainly does report issues of this nature in our tests. Without interacting directly with the target, it's hard to know what other behavior might be happening that might be preventing Burp from reporting the issue. We would suggest using an extension like Custom Logger from the BApp Store, to monitor all the requests made by the Scanner. Then turn off all checks other than open redirection, and see what requests happen during the scan. This might provide some evidence as to why Burp doesn't report an issue.

Burp User | Last updated: Sep 09, 2016 12:03PM UTC