Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP ASM
Known Affected Versions:
11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6
Fixed In:
13.0.0
Opened: May 09, 2016 Severity: 3-Major
Signatures can be evaded using XML/JSON format (and adding the relevant Content-Type header).
An attack is not detected.
1. Configure either a rapid deployment policy or Web Services policy. 2. Add a content profile and set it to parse 'Content-type' header with *json* value as JSON or *xml* as XML. 3. Add the created content profile to a wildcard * Allowed URL. 4. The application ignores the Content-Type header as it always expects form-data values in the payload. 5. A request contains traffic that looks to ASM like JSON or XML while it is actually form-data traffic and the attack signature is decoded inside it using the form-data decoding.
The issue is actually a misconfiguration. If you know that your application doesn't read the Content-Type header, you should configure the system to always take the correct content type.
The system now checks signatures after performing URL decoding on JSON/XML values.