CAPEC-267 - Leverage Alternate Encoding

This attack leverages the possibility to encode potentially harmful input and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 3
  • Injection
  • Protocol Manipulation
  • API Abuse
  • Purposes 1
  • Penetration
  • Sec Principles 1
  • Reluctance to Trust
  • Scopes 10
  • Modify files or directories
  • Integrity
  • Read files or directories
  • Confidentiality
  • Modify application data
  • Integrity
  • Read memory
  • Confidentiality
  • Modify memory
  • Integrity
  • Read application data
  • Confidentiality
  • Execute unauthorized code or commands
  • Authorization
  • Gain privileges / assume identity
  • Non-Repudiation
  • Authorization
  • Authentication
  • Accountability
  • Bypass protection mechanism
  • Authorization
  • Access_Control
  • DoS: resource consumption (other)
  • DoS: resource consumption (memory)
  • DoS: resource consumption (CPU)
  • DoS: instability
  • DoS: crash / exit / restart
  • DoS: amplification
  • Availability

Low level: An attacker can inject different representation of a filtered character in a different encoding.

Medium level: An attacker may craft subtle encoding of input data by using the knowledge that he/she has gathered about the target host.

The application's decoder accepts and interprets encoded characters. Data canonicalization, input filtering and validating is not done properly leaving the door open to harmful characters for the target host.

Attacker may try to inject dangerous characters using different encoding using (example of invalid UTF-8 characters, overlong UTF-8, Chinese characters in Big-5, etc.). The attacker hopes that the targeted system does poor input filtering for all the different possible representations of the malicious characters. Malicious inputs can be sent through an HTML form, directly encoded in the URL or as part of a database query. The attacker can use scripts or automated tools to probe for poor input filtering.

Step 1 - Survey the application for user-controllable inputs

Using a browser, an automated tool or by inspecting the application, an attacker records all entry points to the application..

Tecnique ID: 1 - Environment(s) env-Web

Use a spidering tool to follow and record all links and analyze the web pages to find entry points. Make special note of any links that include parameters in the URL.

Tecnique ID: 2 - Environment(s) env-Web

Use a proxy tool to record all user input entry points visited during a manual traversal of the web application.

Tecnique ID: 3 - Environment(s) env-Web

Use a browser to manually explore the website and analyze how it is constructed. Many browsers' plugins are available to facilitate the analysis or automate the discovery.

Tecnique ID: 4 - Environment(s) env-All

Manually inspect the application to find entry points.

Indicator ID: 1 - Environment(s) env-All env-Web

Type: Positive

Inputs are used by the application or the browser (DOM)

Indicator ID: 2 - Environment(s) env-Web

Type: Inconclusive

Using URL rewriting, parameters may be part of the URL path.

Indicator ID: 3 - Environment(s) env-Web

Type: Inconclusive

No parameters appear to be used by the application. Even though none appear, the application may still use them if they are provided.

Indicator ID: 4 - Environment(s) env-All env-Web

Type: Inconclusive

No inputs seem to be used by the application. They might still be provided to another component (web service, database, system call, etc.).

Indicator ID: 5 - Environment(s) env-Web

Type: Negative

Applications that have only static pages or that simply present information without accepting input are unlikely to be susceptible.


Security Control ID: 1

Type: Detective

Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them).

Security Control ID: 2

Type: Detective

Create links on some pages that are visually hidden from web browsers. Using iframes, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application.

Security Control ID: 3

Type: Preventative

Use CAPTCHA to prevent the use of the application by an automated tool.

Security Control ID: 4

Type: Preventative

Actively monitor the application and either deny or redirect requests from origins that appear to be automated.


Outcome ID: 1

Type: Success

A list of entry points (URL, parameters, configuration files, etc.) is created by the attacker.

Outcome ID: 2

Type: Success

A list of resources accessed by the application is created by the attacker.



Step 1 - Probe entry points to locate vulnerabilities

The attacker uses the entry points gathered in the "Explore" phase as a target list and injects various payloads using a variety of different types of encodings to determine if an entry point actually represents a vulnerability with insufficient validation logic and to characterize the extent to which the vulnerability can be exploited..

Tecnique ID: 1 - Environment(s) env-All env-Web

Try to use different encodings of content in order to bypass validation routines.

Indicator ID: 1 - Environment(s) env-All env-Web

Type: Positive

The application accepts user-controllable input.


Security Control ID: 1

Type: Detective

Monitor inputs to web servers. Alert on unusual charset and/or characters.

Security Control ID: 2

Type: Preventative

Implement input validation routines that canonicalize and filter user submitted content.

Security Control ID: 3

Type: Preventative

Specify the charset of the HTTP transaction/content.

Security Control ID: 4

Type: Preventative

Actively monitor the application and either deny or redirect requests from origins that appear to be attack attempts.


Outcome ID: 1

Type: Success

The attacker's encoded payload is processed and acted on by the application without filtering or transcoding.

Outcome ID: 2

Type: Failure

The application decodes the charset and filters the inputs.



Assume all input might use an improper representation. Use canonicalized data inside the application; all data must be converted into the representation used inside the application (UTF-8, UTF-16, etc.)

Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input.