DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Cookies Revisited: A Networking Solution for Third-Party Cookies
  • Using Event-Driven Ansible to Monitor Your Web Application
  • The Blue Elephant in the Room: Why PHP Should Not Be Ignored Now or Ever
  • Azure Deployment Using FileZilla

Trending

  • Memory Leak Due to Time-Taking finalize() Method
  • Contextual AI Integration for Agile Product Teams
  • AI, ML, and Data Science: Shaping the Future of Automation
  • Power BI Embedded Analytics — Part 2: Power BI Embedded Overview

Cross-Site Scripting in HTTP Headers

Cross-Site Scripting (XSS) is one of the most common vulnerabilities on the web. Learn how you as a developer can guard against it.

By 
Ian Muscat user avatar
Ian Muscat
·
Sep. 04, 17 · Tutorial
Likes (5)
Comment
Save
Tweet
Share
20.7K Views

Join the DZone community and get the full member experience.

Join For Free

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 the 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 an HTTP headers attack is an XSS attack which uses HTTP header fields as entry points for injecting the payload and depends on the 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 with respect to gathering the necessary information that will identify exploitable web applications and exploitable HTTP header fields.

Example

An example of XSS in an 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 the 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. A 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

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.

Prospection (given a list of potentially 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.

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 the 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 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 choose 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 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.

Web application

Published at DZone with permission of Ian Muscat, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Cookies Revisited: A Networking Solution for Third-Party Cookies
  • Using Event-Driven Ansible to Monitor Your Web Application
  • The Blue Elephant in the Room: Why PHP Should Not Be Ignored Now or Ever
  • Azure Deployment Using FileZilla

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!