This article is the second part of OWASP top 10 Common vulnerabilities...
HTTP Header Injection
Vulnerability Description:
This post is the second part of the series OWASP what? and focuses explaining how OWASP categorizes vulnerabilities. So HTTP header injection is a general class of web application security vulnerability which occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input. Header injection in HTTP responses can allow for HTTP response splitting, Session fixation via the Set-Cookie header, cross-site scripting (XSS), and malicious redirects attacks via the location header. HTTP header injection is a relatively new area for web-based attacks, and has primarily been pioneered by Amit Klein in his work on request/response smuggling/splitting. During the web application penetration test, we managed to successfully inject HTTP headers on to the server’s responses.
Impact:
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.
Recommendations:
Investigate all uses of HTTP headers, such as
1. Setting cookies
2. Using location (or redirect() functions)
3. Setting mime-types, content-type, file size, etc.
4. Setting custom headers
If these contain Unvalidated user input, the application is vulnerable when used with application frameworks that cannot detect this issue. If the application has to use user-supplied input in HTTP headers, it should check for double “\n” or “\r\n” values in the input data and eliminate it (along with all it mutation, e.g. encoded return characters).
Many application servers and frameworks have basic protection against HTTP response splitting, but it is not adequate to task, and you should not allow Unvalidated user input in HTTP headers.
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.
References:
Vulnerability Description:
A web application takes a parameter and redirects a user to the parameter value, such a Web site, without validation. Attackers exploit this vulnerability with phishing e-mails that cause users to visit malicious sites inadvertently.
Impact:
Invalidated redirects and forwards vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. This behaviour can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting 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.
HTTP Header Injection
Vulnerability Description:
This post is the second part of the series OWASP what? and focuses explaining how OWASP categorizes vulnerabilities. So HTTP header injection is a general class of web application security vulnerability which occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input. Header injection in HTTP responses can allow for HTTP response splitting, Session fixation via the Set-Cookie header, cross-site scripting (XSS), and malicious redirects attacks via the location header. HTTP header injection is a relatively new area for web-based attacks, and has primarily been pioneered by Amit Klein in his work on request/response smuggling/splitting. During the web application penetration test, we managed to successfully inject HTTP headers on to the server’s responses.
Impact:
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.
Recommendations:
Investigate all uses of HTTP headers, such as
1. Setting cookies
2. Using location (or redirect() functions)
3. Setting mime-types, content-type, file size, etc.
4. Setting custom headers
If these contain Unvalidated user input, the application is vulnerable when used with application frameworks that cannot detect this issue. If the application has to use user-supplied input in HTTP headers, it should check for double “\n” or “\r\n” values in the input data and eliminate it (along with all it mutation, e.g. encoded return characters).
Many application servers and frameworks have basic protection against HTTP response splitting, but it is not adequate to task, and you should not allow Unvalidated user input in HTTP headers.
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.
References:
- https://www.owasp.org/index.php/Interpreter_Injection
- http://en.wikipedia.org/wiki/HTTP_header_injection
- http://blogs.msdn.com/b/esiu/archive/2007/09/22/http-header-injection-vulnerabilities.aspx
Vulnerability Description:
A web application takes a parameter and redirects a user to the parameter value, such a Web site, without validation. Attackers exploit this vulnerability with phishing e-mails that cause users to visit malicious sites inadvertently.
Impact:
Invalidated redirects and forwards vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. This behaviour can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting 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.
Recommendations:
Investigate all uses of HTTP headers, such as
1. Setting cookies
2. Using location (or redirect() functions)
3. Setting mime-types, content-type, file size, etc.
4. Setting custom headers
If these contain Unvalidated user input, the application is vulnerable when used with application frameworks that cannot detect this issue.
If the application has to use user-supplied input in HTTP headers, it should check for double “\n” or “\r\n” values in the input data and eliminate it (along with all it mutation, e.g. encoded return characters).
Many application servers and frameworks have basic protection against HTTP response splitting, but it is not adequate to task, and you should not allow Unvalidated user input in HTTP headers.
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.
References:
- https://www.owasp.org/index.php/Interpreter_Injection
- http://en.wikipedia.org/wiki/HTTP_header_injection
- http://blogs.msdn.com/b/esiu/archive/2007/09/22/http-header-injection-vulnerabilities.aspx
