HTTP Header Injection Reports | HTTPi - Set Cookie PoC | HTTPi - Location Response PoC | HTTPi - Eyeblaster Cookie PoC
CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
The value of REST URL parameter 1 is copied into the Location response header. The payload dcc52%0d%0a267c4eb9467 was submitted in the REST URL parameter 1. This caused a response containing an injected HTTP header.
The value of the si request parameter is copied into the Set-Cookie response header. The payload 15802%0d%0a6fe09aee5f0 was submitted in the si parameter. This caused a response containing an injected HTTP header.
Hoyt LLC Research suggests that the ability to leverage and execute a hidden iFrame in a Victim Browser and gather personal information leveraging these vulnerabilities has already been confirmed as written about in PCWORLD.
HTTP Header Injection | Proof of Concept | Example
The value of REST URL parameter 1 is copied into the Location response header. The payload 2dcae%0d%0a334a66a2653 was submitted in the REST URL parameter 1. This caused a response containing an injected HTTP header.
HTTP Header Injection | CWE-113
A CRLF (New line) injection in HTTP headers was identified. This means that the input goes into HTTP headers without proper input filtering.
Impact
Depending on the application. An attacker might carry out the following forms of attacks:
- Cross-site Scripting attack which can lead to session hijacking
- Session fixation attack by setting a new cookie, which can again lead to session hijacking
Actions to Take
- See the remedy for solution.
- Ensure the server security patches are up to date and that the current stable version of the software is in use.
Remedy
Do not allow newline characters in input. Where possible use strict white listing.
Required Skills for Successful Exploitation
Crafting the attack to exploit this issue is not a complex process. However most of the unsophisticated attackers will not know that such an attack is possible. Also an attacker needs to reach his victim by an e-mail or other similar method in order to entice them to visit the site or click upon a URL.
External References
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.Cross Site Scripting | CWE-79
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
External References
- MSDN - Internet Explorer 8 Security Features
- Internet Explorer 8 XSS Filter
- XSS Cheat Sheet
- OWASP - Cross-site Scripting
Hoyt LLC is committed to protecting and securing end-users and personal information and the Hoyt LLC Research Blog and CDN Exploit Search is visible proof of our effort to provide training, education and knowledge into the Public Domain.
Hoyt LLC Research investigates and reports on security vulnerabilities embedded in Web Applications and Products used in wide-scale deployment. When we fingerprint a critical (with authentication credentials) vulnerability, we develop a Private Security Notification and only disseminate information about the vulnerability, the risk it poses, and what customers can do to protect themselves against it, to the specific Vendor identified.
Non-authenticated vulnerabilities are investigated and report as identified consistent with Full Disclosure, which is immediate and simultaneous with Vendor notification.
Companies large and small need the help of security researchers whom discover emerging and known security vulnerabilities, our investigation and reporting on emerging vulnerabilities provide transparency to an otherwise opaque security picture of applications and products used in wide-scale deployment.
The identification and reporting of emerging and known vulnerabilities is more difficult when details of a vulnerability are made public before by another 3rd party prior to an update being developed. When such events occur, Full Disclosure is our primary consideration, in order to protect the Public against malicious attackers whom may exploit the vulnerability.
The responsibility for all software and hardware products rests with the Vendor alone, and we suggest that Vendors take that responsibility very seriously.
There has traditionally been an unwritten rule among security professionals that the discoverer of an emerging or known security vulnerability has an obligation to give the Vendor an opportunity to correct the vulnerability before publicly disclosing it. Once the Public are protected, Full Disclosure of the vulnerability is entirely in order, and helps the industry at large improve its products.
Hoyt LLC observes these established security research and vulnerability notification practices and comments that a security professional is acknowledged by a Vendor when they reported the vulnerability to a Vendor confidentially, worked with the Vendor to identify the scope and true risk, and helped the Vendor disseminate information about it after the threat was mitigated.
Hoyt LLC further observes that a pay for performance model such as the Google Vulnerability Rewards Program (GVRP) and the recognition model such as that of Microsoft both demonstrate a commitment to Best Practices and end-user security.
About Us
Hoyt LLC Research investigates and reports on security vulnerabilities embedded in Web Applications and Products used in wide-scale deployment.
Hoyt LLC provides litigation expertise with research, forensic analysis and support services targeting the SS7, PSTN and IP Networks.
Please use Live Chat to contact us 7x24x365.
Hoyt LLC Research investigates and reports on security vulnerabilities embedded in Web Applications and Products used in wide-scale deployment. When we fingerprint a critical (with authentication credentials) vulnerability, we develop a Private Security Notification and only disseminate information about the vulnerability, the risk it poses, and what customers can do to protect themselves against it, to the specific Vendor identified.
Non-authenticated vulnerabilities are investigated and report as identified consistent with Full Disclosure, which is immediate and simultaneous with Vendor notification.
Companies large and small need the help of security researchers whom discover emerging and known security vulnerabilities, our investigation and reporting on emerging vulnerabilities provide transparency to an otherwise opaque security picture of applications and products used in wide-scale deployment.
The identification and reporting of emerging and known vulnerabilities is more difficult when details of a vulnerability are made public before by another 3rd party prior to an update being developed. When such events occur, Full Disclosure is our primary consideration, in order to protect the Public against malicious attackers whom may exploit the vulnerability.
The responsibility for all software and hardware products rests with the Vendor alone, and we suggest that Vendors take that responsibility very seriously.
There has traditionally been an unwritten rule among security professionals that the discoverer of an emerging or known security vulnerability has an obligation to give the Vendor an opportunity to correct the vulnerability before publicly disclosing it. Once the Public are protected, Full Disclosure of the vulnerability is entirely in order, and helps the industry at large improve its products.
Hoyt LLC observes these established security research and vulnerability notification practices and comments that a security professional is acknowledged by a Vendor when they reported the vulnerability to a Vendor confidentially, worked with the Vendor to identify the scope and true risk, and helped the Vendor disseminate information about it after the threat was mitigated.
Hoyt LLC further observes that a pay for performance model such as the Google Vulnerability Rewards Program (GVRP) and the recognition model such as that of Microsoft both demonstrate a commitment to Best Practices and end-user security.
About Us
Hoyt LLC Research investigates and reports on security vulnerabilities embedded in Web Applications and Products used in wide-scale deployment.
Hoyt LLC provides litigation expertise with research, forensic analysis and support services targeting the SS7, PSTN and IP Networks.
Please use Live Chat to contact us 7x24x365.
0 comments:
Post a Comment