parameter tampering opportunities are automatically generated analyzing both client and server side codebase, in a white-box fashion. Mismatches between client and server input validation logic are exploited to build application-specific inputs that are mistakenly accepted by the web server. The approach works on the LAMP stack and requires open-source PHP web servers

Context

Client-side validation ease the web server work and improve the user experience. But when the web server fails to replicate the client-side validation, the application is exposed to parameter tampering attacks.

  • HTTP requests can indeed be crafted by hand to circumvent client-side checks
  • a web application can be said as vulnerable to parameter tampering when the server-side parameter validation is weaker than the client-side validation

The correct way to check user input is to duplicate the checks, or to perform even stricter validation on the server side

Contributions

  • a fully automated system to identify validation-related vulnerabilities on the server-side, with a mechanism to confirm these vulnerabilities
  • missing checks on the server-side are identified by analyzing the client-side code, which is used to extract part of the specifications of the desired behavior of the system
  • WAPTEC (Whitebox Analysis for Parameter Tampering Exploit Construction) combine techniques from formal logic and constraint solving, symbolic evaluation and dynamic program analysis to identify missing checks on the server-side

Challenges

  • often a web server uses a different logic to validate the user input (e.g., the client-side accept a string of length <= 10, the server-side accept whatever length but drop each character after the 10th)
  • the client-side does not consider database constraints, therefore these constraints has to be integrated server-side
  • negative tampering: an attacker guessing new parameters to achieve specific goals (e.g., appending a parameter discount hoping to trigger a specific server response in a payment process). Therefore, new checks should be integrated server-side that are not directly derivable from the client

Approach

WAPTEC basic approach is a 2 steps process

  1. finding server control paths that if taken results in an input being accepted (benign input) (e.g., input that lead to sensitive operation such as database updates)
  2. finding inputs leading to server control path that the client rejects (hostile input) (e.g., submitting a negative quantity of a product, which is negated by the client but maybe not by the server)

Benign input The client logic (e.g., HTML form) is analyzed to derive information about the desired input structure. The fclient includes all the logic constraints derivable from the client-side

  • if fclient is not enough for producing a valid input, the logic of fclient is augmented considering additional logic constraints that are derivable from the execution traces of the code the server executes. A new piece of logic is added each time until a benign input is accepted (iterative process)
  • the obtained logic undergoes a perturbation process to find additional sink functions (e.g., the logic constraints are randomly modified to see if new statements are executed server-side)

Hostile input Based on the previous constraints, WAPTEC generates inputs that the server should reject (because were rejected by the client, e.g., by negating certain constraints), but indeed lead to the same functions sinks. It generates variants until accepted inputs are found: that is, tampering candidates.

Parameter tampering are therefore defined as: ¬fclient ∧ fserver, which means “parameters that are rejected by the client but mistakenly accepted by the server”

It’s important to note that the server side behavior is obtained by dynamic analysis of server side code. WAPTEC operates by transforming PHP open-source code (e.g., certain specific functions are overridden to log input parameters) to automatically extract input validation logic on the server-side

Evaluation

6 open source web application were evaluated and 45 previously unknown vulnerabilities were discovered

Limits

  • The proposed solution works on the LAMP stack (Linux, Apache, MySQL, PHP)
  • Works on open source applications whose code is available
  • Evaluation was done on pre-selected applications (no standard benchmark testing)

References