CAPEC

Common Attack Pattern Enumeration and Classification
Common Attack Pattern Enumeration and Classification

A Community Knowledge Resource for Building Secure Software

Home > CAPEC List > Individual CAPEC Dictionary Definition (Release 1.1)   View the CAPEC List

Individual CAPEC Dictionary Definition (Release 1.1)
Individual CAPEC Dictionary Definition (Release 1.1)

Embedding Script (XSS ) in HTTP Headers
Attack Pattern ID
Pattern Abstraction: Detailed

86

Typical Severity

Very High

Description

Summary


An attack of this type exploits web applications that generate web content, such as links in a HTML page, based on unvalidated or improperly validated data submitted by other actors.  XSS in HTTP Headers attacks target the HTTP headers which are hidden from most users and may not be validated by web applications. As with all XSS attacks, there are a number of possible targets:
1. Launch attack on web browser clients and client machine
2. Launch attacks on client machines environment, such as LAN or Intranet
3. Launch attack on web server, including remote web servers

Web 2.0 technologies rely heavily on mashups and other plug in technologies like multi media players which are effectively composed of content generated by other systems and are vulnerable due to the fact that an attacker may use the HTTP header information that these technologies consume and display as an attack launch pad.

Beyond Web 2.0, increasingly system administration software uses web front ends, from firewall administration to application servers, to blogging software, many tools are administered through web browsers. This gives the administrator the ability to administer in a highly distributed environment, but this comes at the cost of exposing the command and control software for the system to web attacks. Additionally, because the rich functionality required these administration applications, many rely on scripting languages. So an attacker can insert HTTP links into logs, audit functionality, error logs, and message queues, then, for example, a Javascript-enabled web browser with administrator rights can be redirected to execute a wide variety of attacks, including those listed here.

As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote attacker to collect and interpret the output of said attack.

Attack Prerequisites

Target software must be a client that allows scripting communication from remote hosts, and attacker must control a remote site of some sort to redirect client and data to.

Typical Likelihood of Exploit

High

Methods of Attack
  • Injection
  • Modification of Resources
  • Protocol Manipulation
Examples-Instances

Description


Utilize a remote style sheet set in the HTTP header for XSS attack. When the attacker is able to point to a remote stylesheet, any of the variables set in that stylesheet are controllable on the client side by the remote attacker. Like most XSS attacks, results vary depending on browser that is used.
(source:http://ha.ckers.org/xss.html)

<META HTTP-EQUIV="Link" Content="<http://ha.ckers.org/xss.css>; REL=stylesheet">
</Example-Instance_Description>
<Example-Instance_Description>
Google's 404 redirection script was found vulnerable to this attack vector.
Google's 404 file not found page read

* Response headers: "Content-Type: text/html; charset=[encoding]".
* Response body: <META http-equiv="Content-Type" (...) charset=[encoding]/>
If the response sends an unexpected encoding type such as UTF-7, then no enforcement is done on the payload and arbitrary XSS code will be transported along with the standard HTTP response. Source: http://seclists.org/fulldisclosure/2005/Dec/1107.html
</Example-Instance_Description>
<Example-Instance_Description>
XSS can be used in variety of ways, because it is scripted and executes in a distribtued, asynchronous fashion it can create its own vector and openings. For example, the attacker can use XSS to mount a DDoS attack by having series of different computers unknowingly executing requests against a single host.

Attacker Skill or Knowledge Required

Low → To achieve a redirection and use of less trusted source, an attacker can simply edit HTTP Headers that are sent to client machine. High → Exploiting a client side vulnerability to inject malicious scripts into the browser’s executable process.

Resources Required

Ability to deploy a custom hostile service for access by targeted clients. Ability to communicate synchronously or asynchronously with client machine

Solutions and Mitigations

Design: Use browser technologies that do not allow client side scripting.

Design: Utilize strict type, character, and encoding enforcement

Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.

Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.

Implementation: Perform input validation for all remote content.

Implementation: Perform output validation for all remote content.

Implementation: Disable scripting languages such as Javascript in browser

Implementation: Session tokens for specific host

Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.

Attack Motivation-Consequences
  • Run Arbitrary Code
  • Information Leakage
  • Privilege Escalation
Context Description


“Attack Pattern: XSS in HTTP Headers
The HTTP headers of a request are always available to a server for consumption. No matter the context or where data are positioned., if the data are from the client, they should clearly be untrusted. However in many cases programmers overlook header information. For some reason header information is treated as holy ground that cannot be controlled by the user. This pattern takes advantage of this oversight to inject data via a header field.
[Hoglund and McGraw 04]

Injection Vector

Malicious input delivered through HTTP Headers.

Payload

Varies with instantiation of attack pattern. In the case of HTTP headers they may not be visible to the end user via a browser

Activation Zone

Header processing on the server or Client browser

Payload Activation Impact

Enables attacker to execute scripts to launch attacks on server as well as remote client machine and environment

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
79Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))Targeted
184Incomplete BlacklistSecondary
348Use of Less Trusted SourceTargeted
96Insufficient Control of Directives in Statically Saved Code (Static Code Injection)Targeted
20Insufficient Input ValidationTargeted
116Incorrect Output SanitizationTargeted
86Invalid Characters in IdentifiersSecondary
Related Vulnerabilities
Vulnerability-IDVulnerability Description
CVE-2006-5442 Summary: ViewVC 1.0.2 and earlier does not specify a charset in its HTTP headers or HTML documents, which allows remote attackers to conduct cross-site scripting (XSS) attacks that inject arbitrary UTF-7 encoded JavaScript code via a view.
CVE-2006-3918 Summary: http_protocol.c in (1) IBM HTTP Server 6.0 before 6.0.2.13 and 6.1 before 6.1.0.1, and (2) Apache HTTP Server 1.3 before 1.3.35, 2.0 before 2.0.58, and 2.2 before 2.2.2, does not sanitize the Expect header from an HTTP request when it is reflected back in an error message, which might allow cross-site scripting (XSS) style attacks using web client components that can send arbitrary headers in requests, as demonstrated using a Flash SWF file.
Purpose

Penetration

Exploitation

CIA Impact
Confidentiality ImpactIntegrity ImpactAvailability Impact
HighHighHigh
Technical Context
Architectural ParadigmFrameworkPlatformLanguage
Client-ServerAllAllAll
References

G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.

Source
Submission(s)
SubmitterOrganizationDateComment
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.Cigital, Inc2007-01-01
Modification(s)
ModifierOrganizationDateComment
Gunnar PetersonCigital, Inc2007-02-28Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"
Sean BarnumCigital, Inc2007-03-09Review and revise
Richard StruseVOXEM, Inc2007-03-26Review and feedback leading to changes in Name
Sean BarnumCigital, Inc2007-04-16Modified pattern content according to review and feedback
 
Page Last Updated: April 18, 2008