Difference between revisions of "WAF 330792"
| (One intermediate revision by one user not shown) | |||
| Line 17: | Line 17: | ||
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 client side application (browser, application, etc.) is generating either non-RFC compliant, or broken message bodies that the WAF is unable to assemble. This can | + | 2) The client side application (browser, application, etc.) is generating either non-RFC compliant, or broken message bodies that the WAF is unable to assemble. This can also ccur with a broken server side application that does not follow RFCs and is generating broken multi part messages, or a combination of non-compliant clients, buggy libraries or even a broken connection. |
'''False Positives''' | '''False Positives''' | ||
| − | There are no known false positives for this rule. Disabling this rule will leave your system open to multipart bypass 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. | + | There are no known false positives for this rule. Disabling this rule will leave your system open to multipart bypass 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. Broken applications that create this condition are '''extremely rare''', and it is not recommended that you disable this rule if you have a false positive. We recommend that you first attempt to reproduce this condition. Often this is caused by a temporary broken connection from the client, a bug in the client or web application or a evan just a corrupt request. If this is intermittent, then the issue is a broken connection or an intermittent problem on the client that is corrupting the request. |
| − | If this occurs consistently with the client, then it is most likely a bug in the clients implementation for multipart messages and this condition should be reported to the developer for further investigation. | + | If this occurs consistently with the client, then it is most likely a bug in the clients implementation for multipart messages or the server side application and this condition should be reported to the developer for further investigation. |
| − | 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. 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. | + | If your application or client is generating broken multi-part messages, we highly recommend you have the developer fix this condition. Disabling this rule for applications that generate broken multi-part messages will leave you open to attack on these applications. The WAF will not be able to correctly assemble these messages, even if the rule is disabled. This rule is protecting the system from a condition where the WAF will be unable to correctly scan this request for malicious activity. |
| + | |||
| + | If you believe this is a true false positive, that is there are no connection errors, and neither the client nor the server side application is generating requests that would lead to broken multipart messages then please report this to our security team to determine if this is a legitimate case, or if its clever attack on your system. 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''' | ||
| − | 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. | + | 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 just that application to generate bodies the WAF can not examine correctly. Please see the [[Tuning the Atomicorp WAF Rules]] page for basic information. |
| + | |||
| + | We do not recommend you do this. Applications should not generate broken multi-part messages. The correct solution is to fix the application. Disabling this rule for an application is the same thing as disabling the entire WAF for the application. Attackers will be able to use broken multi-part messages to bypass the WAF, and this method is widely used by attackers. | ||
'''Similar Rules''' | '''Similar Rules''' | ||
Latest revision as of 17:56, 17 July 2012
Rule ID
330792
Status
Active rule currently published.
Alert Message
Multipart parser detected a possible unmatched boundary. 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, during the parsing phase of a multipart/request-body, ModSecurity encounters what the client has presented as a boundary but it is not. Such an event may occur when evasion of ModSecurity is attempted. 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 (browser, application, etc.) is generating either non-RFC compliant, or broken message bodies that the WAF is unable to assemble. This can also ccur with a broken server side application that does not follow RFCs and is generating broken multi part messages, or a combination of non-compliant clients, buggy libraries or even a broken connection.
False Positives
There are no known false positives for this rule. Disabling this rule will leave your system open to multipart bypass 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. Broken applications that create this condition are extremely rare, and it is not recommended that you disable this rule if you have a false positive. We recommend that you first attempt to reproduce this condition. Often this is caused by a temporary broken connection from the client, a bug in the client or web application or a evan just a corrupt request. If this is intermittent, then the issue is a broken connection or an intermittent problem on the client that is corrupting the request.
If this occurs consistently with the client, then it is most likely a bug in the clients implementation for multipart messages or the server side application and this condition should be reported to the developer for further investigation.
If your application or client is generating broken multi-part messages, we highly recommend you have the developer fix this condition. Disabling this rule for applications that generate broken multi-part messages will leave you open to attack on these applications. The WAF will not be able to correctly assemble these messages, even if the rule is disabled. This rule is protecting the system from a condition where the WAF will be unable to correctly scan this request for malicious activity.
If you believe this is a true false positive, that is there are no connection errors, and neither the client nor the server side application is generating requests that would lead to broken multipart messages then please report this to our security team to determine if this is a legitimate case, or if its clever attack on your system. 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 just that application to generate bodies the WAF can not examine correctly. Please see the Tuning the Atomicorp WAF Rules page for basic information.
We do not recommend you do this. Applications should not generate broken multi-part messages. The correct solution is to fix the application. Disabling this rule for an application is the same thing as disabling the entire WAF for the application. Attackers will be able to use broken multi-part messages to bypass the WAF, and this method is widely used by attackers.
Similar Rules
Knowledge Base Articles
None.
Outside References
None.
