Difference between revisions of "WAF 330791"
m |
|||
| (2 intermediate revisions by one user not shown) | |||
| Line 9: | Line 9: | ||
'''Alert Message''' | '''Alert Message''' | ||
| − | Failed to parse request body. This may be an impedence mismatch attack, a broken application or a broken connection. This is not a false positive. Check your application or client for errors | + | Failed to parse request body. This may be an impedence mismatch attack, a broken application or a broken connection. This is not a false positive. Check your application or client for errors. |
'''Description''' | '''Description''' | ||
| Line 16: | Line 16: | ||
1) An attacker is attempting to bypass the WAF by constructing a body that will not be parsed correctly by the WAF, in hopes of bypassing the WAF. | 1) An attacker is attempting to bypass the WAF by constructing a body that will not be parsed correctly by the WAF, in hopes of bypassing the WAF. | ||
| − | 2) The application is generating non-RFC compliant, or broken message | + | |
| + | 2) The client side application and/or server side application is generating a non-RFC compliant, or broken message body that the WAF is unable to assemble. This can occur with a broken application, broken client, buggy library or even a temporary broken connection. | ||
'''False Positives''' | '''False Positives''' | ||
| − | Disabling this rule will leave your system open for impedance mismatch attacks, therefore it is highly recommended you first discuss this issue with the applications developers to determine why the format of the request is unparsable, and determine if they can fix their application first. This condition is extremely rare | + | Disabling this rule will leave your system open for impedance mismatch attacks, therefore it is highly recommended you first discuss this issue with the applications developers to determine why the format of the request is unparsable, and determine if they can fix their application first. This condition is extremely rare and is almost always caused by a buggy application on the clients side. It is not recommended that you disable this rule if you have a false positive. |
| + | |||
| + | If you believe this is a false positive, please report this to our security team to determine if this is a legitimate case or if its clever attack on your system. If you know this is not an attack, please provide any and all information the application developer provided that shows the request is compliant and that there is not a bug on the client side. | ||
| − | + | Instructions to report false positives are detailed on the [[Reporting False Positives]] wiki page. If it is a false positive, we will fix the issue in the rules and get a release out to you promptly. | |
'''Tuning Guidance''' | '''Tuning Guidance''' | ||
Latest revision as of 16:49, 15 June 2012
Rule ID
330791
Status
Active rule currently published.
Alert Message
Failed to parse request body. This may be an impedence mismatch attack, a broken application or a broken connection. This is not a false positive. Check your application or client for errors.
Description
This rule detects when the request body processor, used for request body parsing, is unable to parse the body of the request. This is a serious condition, and can mean only one of two things:
1) An attacker is attempting to bypass the WAF by constructing a body that will not be parsed correctly by the WAF, in hopes of bypassing the WAF.
2) The client side application and/or server side application is generating a non-RFC compliant, or broken message body that the WAF is unable to assemble. This can occur with a broken application, broken client, buggy library or even a temporary broken connection.
False Positives
Disabling this rule will leave your system open for impedance mismatch attacks, therefore it is highly recommended you first discuss this issue with the applications developers to determine why the format of the request is unparsable, and determine if they can fix their application first. This condition is extremely rare and is almost always caused by a buggy application on the clients side. It is not recommended that you disable this rule if you have a false positive.
If you believe this is a false positive, please report this to our security team to determine if this is a legitimate case or if its clever attack on your system. If you know this is not an attack, please provide any and all information the application developer provided that shows the request is compliant and that there is not a bug on the client side.
Instructions to report false positives are detailed on the Reporting False Positives wiki page. If it is a false positive, we will fix the issue in the rules and get a release out to you promptly.
Tuning Guidance
If you know that this behaviour is acceptable for your application, you can tune it by identifying the application that is being triggered, and specifically allowing that application to generate bodies the WAF can not examine correctly. Please see the Tuning the Atomicorp WAF Rules page for basic information.
Similar Rules
Knowledge Base Articles
None.
Outside References
None.
