Cross-Site Scripting in HTTP Headers

What is XSS in HTTP Headers and How is it Different when Compared to Other XSS Attacks?

When looking at various types of XSS attacks, we can easily identify the common pattern – it revolves around injecting malicious code into various areas of the HTML pages to be rendered, so that the code gets executed by the browser. However, since XSS is one of the most common web attacks targeted at compromising web sites or web applications, developers are taking precautions to make sure that the common XSS attack vectors are blocked; they sanitize user input before processing at server level (protects against generic XSS attacks), parse the body of the HTML page before serving it back (protects against blind XSS attacks), etc.

In response, hackers try to discover ways of injecting code in areas commonly overlooked by developers and totally transparent to the client user. One such area is the HTTP header of crafted HTTP requests, so instead of encoding malicious scripts in URLs or user input, hackers place the malicious scripts in the HTTP headers following a well-established flow.

Cross-site scripting in HTTP headers attack is an XSS attack which uses HTTP header fields as entry points for injecting the payload, and depends on improper return of user controlled HTTP header values in HTTP responses. It is a usually a reflected XSS attack that uses entry points other than visible user input in web pages or URLs.

The web applications that are vulnerable to this type of attack are the ones which generate web content / expose links in HTML pages based on user input and / or make use of HTTP header variables. Generally the process of enacting such an XSS attack is more elaborated than performing a normal XSS attack, particularly in respect to gathering the necessary information that will identify exploitable web applications and exploitable HTTP header fields.

Example

An example of XSS in HTTP header is illustrated here by Yasser ABOUKIR, who found a vulnerability in Oracle’s HTTP server and demonstrated the attack. The researcher exploited the fact that the server did not sanitize the Expect header field from HTTP requests, when it is reflected back in error messages, thus allowing injection of malicious code in the value of the Expect field of the HTTP header, which in turn gets executed by client browser.

Although the time to perform the attack is around 2 minutes, the research work required to make this attack happen, took much longer. Successful exploitation of cross-site scripting attacks using HTTP header injection highly depends on the basic steps below – most of them are research-oriented.

Anatomy

1. Preparation (given a target website):
   1. The attacker identifies / records all links on the target and analyzes the web pages to find potential entry points;
   2. The details of the links that include parameters that are used in the HTTP headers are noted;
   3. The entry points (user input) that become part of the HTTP header are recorded.

Tools: spidering tools, proxy tools, browser.

Outcomes: a list of links and entry points which may be exploitable.

1. Prospection (given a list of potential vulnerable links and entry points):
   1. The attacker injects various payloads into the entry points identified during the preparation step, in order to identify the ones  which are vulnerable to XSS;
   2. The server responses that include the unaltered script (same as initial payload) are recorded;
   3. The attacker injects additional parameters into the request and observes if they are reflected in the server response.

Tools: automatic injection tools for probing multiple payloads, links; proxy tools to analyze results.

Outcomes: a list of links and entry points which are vulnerable to XSS.

1. Exploitation – no different than in the case of other XSS attacks, may result in:
   1. Data theft: session ids, authentication cookies, page content, etc.;
   2. Redirection to malicious content;
   3. Loss of control / forceful browsing: the attacker uses client browser to perform further attacks
   4. Content spoofing;

More details on the internals of XSS in HTTP headers can be found here.

Defending Against XSS in HTTP Headers

Sanitization

The best defense in this case, like in the case of other XSS attacks is sanitization. Developers can make sure that user input does not make it into server generated HTML headers unless really necessary. This way, the prerequisites for this type of attack are eliminated. However, there are cases where user input needs to be encoded in the HTTP headers and, in these situations, developers can implement filters that sanitize this content and eliminates any scripting tags, thus removing the possibility of exploiting potential entry points that meet the prerequisites of this type of attack.

CAPTCHA

CAPTCHA can be used to prevent automated tools from probing the web pages. While this will not guarantee that your web application or web page is immune to XSS in HTTP headers, it will make the preparation and prospecting steps very difficult for the attacker.

Implement active measures to filter HTTP requests

Developers can implement filtering of HTTP requests and chose to deny or redirect requests which are potentially dangerous:

• Requests coming from automated origins (determined by speed of incoming requests)
• Requests containing XSS-like structures

These measures may help in most of the cases, but they may also generate a lot of false positives and interfere with the normal operations of the website or web application. Similar measures have been implemented by suppliers of web browsing technology (Microsoft X-XSS filter, etc.) as add-ons to their browsers, meant to sanitize HTML responses before the browser executes them but the outcomes are debatable. Several of the top websites in terms of popularity enforce the use of such filters, but others do not because of false positives.

Proactive monitoring

Code is not always available, code reviews and code-based prevention measures take time and money to implement. Proactive monitoring and testing the web technology with appropriate penetration testing tools is one of the best ways of making sure that the current web applications that you own are not susceptible to such an attack. If you find exploitable vulnerabilities using web vulnerability scanners, you will also get sufficient information that will allow easy remediation of the affected areas.

THE AUTHOR

Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.