| Attack Pattern ID | Pattern Abstraction: Standard 63 |
| Typical Severity | Very High |
| Description | Summary An attacker embeds malicious scripts in content that will be served to web browsers. The goal of the attack is for the target software, the client-side browser, to execute the script with the users’ privilege level. An attack of this type exploits a programs' vulnerabilities that are brought on by allowing remote hosts to execute code and scripts. Web browsers, for example, have some simple security controls in place, but if a remote attacker is allowed to execute scripts (through injecting them in to user-generated content like bulletin boards) then these controls may be bypassed. Further, these attacks are very difficult for an end user to detect. 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 scripting, mashups of various remote content sources and other plug in technologies like multi media players which are effectively composed of content generated by other systems 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.
While Ajax and related Web 2.0 technologies are highly prized for rich client experience on web applications, they lack the ability to enforce security policy on the client side. The standard call for an Ajax application is XML HTTP Request (XHR), which by design limits its communication back to its URL host, however it is commonplace for developers to proxy communication from the host to other sites. In this case the client has no ability to 1) know that the communication is proxied in the first place and 2) know where the content is served from and 3) what intermediaries are involved who can sniff and tamper with data in transit.
Ajax does not necessarily introduce additional attack targets, but it does enhance the attacker's ability to execute attacks, probes, and enumerations, because Ajax client-server communications consist of numerous round trips. In classic XSS, the remote attacker may get only one chance to attempt an attack, and if she guesses wrong then needs to move on. In an Ajax scenario, it is likely the attacker can probe for multiple weaknesses, subnets, password combinations, and so on. The "lock" on the safe remains the same, but the attacker can try many combinations.
This lack of assurance on the client side opens up two main vectors for attackers, 1) the attacker can push code to launch attacks on the client system or network, and 2) the attacker can lure the client to malicious sites and to asserting information such as authentication or personal data to the malicious site.
|
| Attack Prerequisites |
Target client software must be a client that allows scripting communication from remote hosts, such as a Javascript-enabled Web Browser
|
| Typical Likelihood of Exploit |
High
|
| Methods of Attack | - Injection
- Modification of Resources
- Protocol Manipulation
|
| Examples-Instances | Description Classic phishing attacks lure users to click on content that appears trustworthy, such as logos, and links that seem to go to their trusted financial institutions and online auction sites. But instead the attacker appends malicious scripts into the otherwise innocent appearing resources. The HTML source for a standard phishing attack looks like this <a href="www.exampletrustedsite.com?Name=<script>maliciousscript</script>">Trusted Site</a> When the user clicks the link, the appended script also executes on the local user's machine.
|
| Attacker Skill or Knowledge Required |
Low → To achieve a redirection and use of less trusted source, an attacker can simply place a script in bulletin board, blog, wiki, or other user-generated content site that are echoed back to other client machines.
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: 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
- Data Modification
- Information Leakage
|
| Context Description | “Attack Pattern: Simple Script Injection "As a normal user of a system there are opportunities to supply input to the system. This input may include text, numbers, cookies, parameters, and so forth. Once these values are accepted by the system, they may be stored, and used later. If the data are used in a server response (such as a message board, where the data are stored and then displayed back to the users), an attacker can "pollute" these data with code that will be interpreted by unsuspecting client terminals." [Hoglund and McGraw 04]
|
| Injection Vector |
Malicious input delivered through standard content (containing scripts) that is sent to the user's machine, for example HTML page containing Javascript.
|
| Payload |
Varies with instantiation of attack pattern. Malicious script payload may be appended to end of legitimate looking link
|
| Activation Zone |
Client browser, its component libraries, and client network (e..g Intranet)
|
| Payload Activation Impact |
Enables attacker to execute scripts to launch attacks on remote client machine and environment. Intranet and local systems may not be patched to the same degree as "externally" facing systems, so simple attacks may identify more victims on an "internal" system such as a corporate Intranet
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 20 | Insufficient Input Validation | Targeted | | 184 | Incomplete Blacklist | Secondary | | 96 | Insufficient Control of Directives in Statically Saved Code (Static Code Injection) | Targeted | | 113 | Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting') | Targeted | | 348 | Use of Less Trusted Source | Targeted | | 116 | Incorrect Output Sanitization | Targeted | | 350 | Improperly Trusted Reverse DNS | Targeted | | 86 | Invalid Characters in Identifiers | Secondary |
|
| Related Attack Patterns | | ID | Name | Relationship Type | Relationship Description |
|---|
| 18 | Embedding Scripts in Nonscript Elements | More Abstract | |
|
| Purpose | Penetration Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | High |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| Client-Server | J2EE | All | JSP |
|
| References |
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
|
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-01-01 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Gunnar Peterson | Cigital, Inc | 2007-02-28 | Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" | | Sean Barnum | Cigital, Inc | 2007-03-09 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Description | | Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback |
|