Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Mystery URL tested as HTTP response header injection error

Sudhakar | Last updated: Nov 23, 2015 11:55PM UTC

After upgrading to version 1.6.30, found 4 critical errors. After debugging the issue seems like to tool is arbitrarily has a bug. See below for more details. Severe error category: HTTP response header injection. Basically the test case is trying to introduce a newline char in the URL and try to see if that can introduce anything on response header. Unfortunately I have 4 URL's for which instead of introducing newline char in the path, its using some weird string. In the below example, it is doing GET on GET /be6af%0df0ad2 HTTP/1.1 Host: MYURL:10440 instead of GET /your-babys-%0ddevelopment HTTP/1.1 Host: MYURL:10440 Example:(masked MYURL) 1.4. https://MYURL:10440/your-babys-development [URL path filename] Severity: High Confidence: Certain Host: https://MyURL:10440 Path: /your-babys-development Issue detail The value of the URL path filename is copied into the Location response header. The payload be6af[0x0d]f0ad2 was submitted in the URL path filename. This caused a response containing an injected HTTP header. Request: GET /be6af%0df0ad2 HTTP/1.1 Host: MYURL:10440 Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Response: HTTP/1.0 301 Moved Permanently Date: Fri, 20 Nov 2015 05:14:50 GMT Server: Apache/2.2.15 (CentOS) mod_jk/1.2.37 mod_ssl/2.2.15 OpenSSL/1.0.0-fips X-Frame-Options: SAMEORIGIN, SAMEORIGIN Location: http://MYURL:10387/be6aff0ad2 Cache-Control: max-age=0 Expires: Fri, 20 Nov 2015 05:14:50 GMT Content-Length: 265 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="MYURL. ...[SNIP]... Appreciate if you can fix the bug soon. Also share the word around if any to suppress this error from active scan.

PortSwigger Agent | Last updated: Nov 24, 2015 03:53PM UTC

From your description, it sounds like Burp is reporting the HTTP header injection issue at a particular path (/your-babys-development) but the request reported in the issue has replaced that path with something else. Is that right? If that is what is happening, then the issue is perfectly real - it is just that Burp could be a bit clearer in its labelling of the affected path. The problem arises because Burp reports the path that it scanned, but the payload that worked has modified the path to the extent that the original filename has been lost. We'll look at changing Burp so that in this situation it drops the filename part from the reported path that the issue resides at.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.