CAPEC-85
Alerte pour un CAPEC
Stay informed of any changes for a specific CAPEC.
Description
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.
Informations
Execution Flow
1) Explore
[Send request to target webpage and analyze HTML] Using a browser or an automated tool, an adversary sends requests to a webpage and records the received HTML response. Adversaries then analyze the HTML to identify any known underlying JavaScript architectures. This can aid in mappiong publicly known vulnerabilities to the webpage and can also helpo the adversary guess application architecture and the inner workings of a system.
Technique
- Record all "src" values inside script tags. These JavaScript files are compared to lists of files for known architectures. If there is a large match between the "src" values and architecture files, then it can be assumed that particular architecture is being used.
Prerequisites
The user must allow JavaScript to execute in their browserSkills Required
To land and launch a script on victim's machine with appropriate footprinting logic for enumerating services and vulnerabilities in JavaScriptResources Required
None: No specialized resources are required to execute this type of attack.Mitigations
Design: Use browser technologies that do not allow client side scripting.Implementation: Perform input validation for all remote content.
Related Weaknesses
| Weakness Name | |
|---|---|
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. |
|
| Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers. |
|
| Use of Less Trusted Source The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack. |
|
| Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template. |
|
| Improper Input Validation The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. |
|
| Improper Encoding or Escaping of Output The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved. |
|
| Incomplete List of Disallowed Inputs The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete. |
|
| Improper Neutralization of Invalid Characters in Identifiers in Web Pages The product does not neutralize or incorrectly neutralizes invalid characters or byte sequences in the middle of tag names, URI schemes, and other identifiers. |
|
| Incomplete Denylist to Cross-Site Scripting The product uses a denylist-based protection mechanism to defend against XSS attacks, but the denylist is incomplete, allowing XSS variants to succeed. |
References
REF-539
Ajax fingerprinting for Web 2.0 ApplicationsShreeraj Shah.
https://www.helpnetsecurity.com/dl/articles/Ajax_fingerprinting.pdf
Submission
| Name | Organization | Date | Date Release |
|---|---|---|---|
| CAPEC Content Team | The MITRE Corporation |
Modifications
| Name | Organization | Date | Comment |
|---|---|---|---|
| CAPEC Content Team | The MITRE Corporation | Updated References | |
| CAPEC Content Team | The MITRE Corporation | Updated Description, Example_Instances, Execution_Flow, Mitigations, Related_Attack_Patterns, Resources_Required, Typical_Severity | |
| CAPEC Content Team | The MITRE Corporation | Updated @Name, Related_Attack_Patterns | |
| CAPEC Content Team | The MITRE Corporation | Updated Related_Weaknesses | |
| CAPEC Content Team | The MITRE Corporation | Updated Execution_Flow |
2024©
tesweb SA
