HTTP header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way. If an attacker can inject newline characters into the header, then they can inject new HTTP headers and also, by injecting an empty line, break out of the headers into the message body and write arbitrary content into the application's response.
Various kinds of attack can be delivered via HTTP header injection vulnerabilities. Any attack that can be delivered via cross-site scripting can usually be delivered via header injection, because the attacker can construct a request which causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage header injection vulnerabilities to poison the cache of any proxy server via which users access the application. Here, an attacker sends a crafted request which results in a "split" response containing arbitrary content. If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a "stored" attack against this URL which will compromise other users who request that URL in future.
Issue remediation
If possible, applications should avoid copying user-controllable data into HTTP response headers. If this is unavoidable, then the data should be strictly validated to prevent header injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into headers, and any other input should be rejected. At a minimum, input containing any characters with ASCII codes less than 0x20 should be rejected.
The value of REST URL parameter 2 is copied into the Location response header. The payload 7be7b%0d%0acead95c525e was submitted in the REST URL parameter 2. This caused a response containing an injected HTTP header.
The value of REST URL parameter 2 is copied into the Location response header. The payload c2255%0d%0a63fbf810e36 was submitted in the REST URL parameter 2. This caused a response containing an injected HTTP header.
The value of REST URL parameter 3 is copied into the Location response header. The payload 9e923%0d%0a59a690263f0 was submitted in the REST URL parameter 3. This caused a response containing an injected HTTP header.
Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application which causes a redirection to an arbitrary external domain. This behaviour can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targetting the correct domain with a valid SSL certificate (if SSL is used) lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.
Remediation background
If possible, applications should avoid incorporating user-controllable data into redirection targets. In many cases, this behaviour can be avoided in two ways:
Remove the redirection function from the application, and replace links to it with direct links to the relevant target URLs.
Maintain a server-side list of all URLs that are permitted for redirection. Instead of passing the target URL as a parameter to the redirector, pass an index into this list.
If it is considered unavoidable for the redirection function to receive user-controllable input and incorporate this into the redirection target, one of the following measures should be used to minimize the risk of redirection attacks:
The application should use relative URLs in all of its redirects, and the redirection function should strictly validate that the URL received is a relative URL.
The application should use URLs relative to the web root for all of its redirects, and the redirection function should validate that the URL received starts with a slash character. It should then prepend http://yourdomainname.com to the URL before issuing the redirect.
The application should use absolute URLs for all of its redirects, and the redirection function should verify that the user-supplied URL begins with http://yourdomainname.com/ before issuing the redirect.
The value of the destUrl request parameter is used to perform an HTTP redirect. The payload .a8e58dbf7460177df/ was submitted in the destUrl parameter. This caused a redirection to the following URL:
http://dw.com.com.a8e58dbf7460177df/
The application attempts to prevent redirection attacks by prepending an absolute prefix to the user-supplied URL. However, this prefix does not include a trailing slash, so an attacker can add an additional domain name to point to a domain which they control.
Remediation detail
When prepending an absolute prefix to the user-supplied URL, the application should ensure that the prefixed domain name is followed by a slash.
Request
GET /redir?ttag=www.Groupon.com/Orange-County&ontid=12&ptid=2003&edid=3&siteid=3<ype=bidwar_madison&ctype=bidwar-channel&cval=news-content-mpu2;ca-cnet-news-content&destUrl=.a8e58dbf7460177df/ HTTP/1.1 Host: dw.com.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: XCLGFbrowser=Cg8ILkzXCxkIAAAAIiM;
Response
HTTP/1.1 302 Found Date: Sun, 07 Nov 2010 20:58:09 GMT Server: Apache/2.0 Pragma: no-cache Cache-control: no-cache, must-revalidate, no-transform Vary: * Expires: Fri, 23 Jan 1970 12:12:12 GMT Location: http://dw.com.com.a8e58dbf7460177df/ Content-Length: 0 P3P: CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa IVAi IVDi CONi OUR OTRi IND PHY ONL UNI FIN COM NAV INT DEM STA" Keep-Alive: timeout=363, max=688 Connection: Keep-Alive Content-Type: text/plain
The value of the destUrl request parameter is used to perform an HTTP redirect. The payload .a1101fcbfa90f41a3/ was submitted in the destUrl parameter. This caused a redirection to the following URL:
http://dw.com.com.a1101fcbfa90f41a3/
The application attempts to prevent redirection attacks by prepending an absolute prefix to the user-supplied URL. However, this prefix does not include a trailing slash, so an attacker can add an additional domain name to point to a domain which they control.
Remediation detail
When prepending an absolute prefix to the user-supplied URL, the application should ensure that the prefixed domain name is followed by a slash.
The value of the destUrl request parameter is used to perform an HTTP redirect. The payload .a6609375da8d32135 was submitted in the destUrl parameter. This caused a redirection to the following URL:
http://dw.com.com.a6609375da8d32135
The application attempts to prevent redirection attacks by prepending an absolute prefix to the user-supplied URL. However, this prefix does not include a trailing slash, so an attacker can add an additional domain name to point to a domain which they control.
Remediation detail
When prepending an absolute prefix to the user-supplied URL, the application should ensure that the prefixed domain name is followed by a slash.
Request
GET /rubicsclk?ver=2&ts=2010.11.07.12.24.48.PST&edId=3&onId=1&ptId=2000&sId=3&appId=19&offId=10316&unitId=45&poolId=1&f1=1&f2=-0&f3=-0&alg=8&&opt=1&linkPos=0&destUrl=.a6609375da8d32135 HTTP/1.1 Host: dw.com.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: XCLGFbrowser=Cg8ILkzXCxkIAAAAIiM;
Response
HTTP/1.1 302 Found Date: Sun, 07 Nov 2010 20:58:31 GMT Server: Apache/2.0 Pragma: no-cache Cache-control: no-cache, must-revalidate, no-transform Vary: * Expires: Fri, 23 Jan 1970 12:12:12 GMT Location: http://dw.com.com.a6609375da8d32135 Content-Length: 0 P3P: CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa IVAi IVDi CONi OUR OTRi IND PHY ONL UNI FIN COM NAV INT DEM STA" Keep-Alive: timeout=363, max=782 Connection: Keep-Alive Content-Type: text/plain
3. Cookie scoped to parent domainpreviousnext There are 2 instances of this issue:
A cookie's domain attribute determines which domains can access the cookie. Browsers will automatically submit the cookie in requests to in-scope domains, and those domains will also be able to access the cookie via JavaScript. If a cookie is scoped to a parent domain, then that cookie will be accessible by the parent domain and also by any other subdomains of the parent domain. If the cookie contains sensitive data (such as a session token) then this data may be accessible by less trusted or less secure applications residing at those domains, leading to a security compromise.
Issue remediation
By default, cookies are scoped to the issuing domain and all subdomains. If you remove the explicit domain attribute from your Set-cookie directive, then the cookie will have this default scope, which is safe and appropriate in most situations. If you particularly need a cookie to be accessible by a parent domain, then you should thoroughly review the security of the applications residing on that domain and its subdomains, and confirm that you are willing to trust the people and systems which support those applications.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure can prevent certain client-side attacks, such as cross-site scripting, from trivially capturing the cookie's value via an injected script.
Issue remediation
There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.
You should be aware that the restrictions imposed by the HttpOnly flag can potentially be circumvented in some circumstances, and that numerous other serious attacks can be delivered by client-side script injection, aside from simple cookie stealing.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The TRACE method is designed for diagnostic purposes. If enabled, the web server will respond to requests which use the TRACE method by echoing in its response the exact request which was received.
Although this behaviour is apparently harmless in itself, it can sometimes be leveraged to support attacks against other application users. If an attacker can find a way of causing a user to make a TRACE request, and can retrieve the response to that request, then the attacker will be able to capture any sensitive data which is included in the request by the user's browser, for example session cookies or credentials for platform-level authentication. This may exacerbate the impact of other vulnerabilities, such as cross-site scripting.
Issue remediation
The TRACE method should be disabled on the web server.
The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site which robots are allowed, or not allowed, to crawl and index.
The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to identify restricted or private areas of a site's contents. The information in the file may therefore help an attacker to map out the site's contents, especially if some of the locations identified are not linked from elsewhere in the site. If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.
Issue remediation
The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons. You should not assume that all web robots will honour the file's instructions. Rather, assume that attackers will pay close attention to any locations identified in the file. Do not rely on robots.txt to provide any kind of protection over unauthorised access.
Request
GET /robots.txt HTTP/1.0 Host: dw.com.com
Response
HTTP/1.1 200 OK Date: Sun, 07 Nov 2010 20:41:00 GMT Server: Apache/2.0 Last-Modified: Tue, 05 Oct 2010 02:01:06 GMT Accept-Ranges: bytes Content-Length: 854 Cache-Control: max-age=14400 Expires: Mon, 08 Nov 2010 00:41:00 GMT P3P: CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa IVAi IVDi CONi OUR OTRi IND PHY ONL UNI FIN COM NAV INT DEM STA" Keep-Alive: timeout=363, max=788 Connection: Keep-Alive Content-Type: text/plain