Difference between revisions of "WAF 351000"
(Created page with "'''Rule ID''' 351000 '''Status''' Active rule currently published. '''Alert Message''' Atomicorp.com Upload Malware Scanner: Malicious File upload attempt detected and...") |
m (ue) |
||
| Line 14: | Line 14: | ||
This rule use the ASL malicious upload scanning engine. This rule will trigger if the malicious upload scanning engine detects that a user attempted to upload a potentially malicious file. | This rule use the ASL malicious upload scanning engine. This rule will trigger if the malicious upload scanning engine detects that a user attempted to upload a potentially malicious file. | ||
| + | |||
'''False Positives''' | '''False Positives''' | ||
| Line 28: | Line 29: | ||
'''Similar Rules''' | '''Similar Rules''' | ||
| + | |||
None. | None. | ||
| Line 37: | Line 39: | ||
None. | None. | ||
| + | |||
| + | '''Notes''' | ||
| + | |||
| + | File uploads in web servers occur before other modules are processed. This is because the web server has to accept the full request from the client, parse it, and then decide how to handle it. This is not a bug in the web server, or the upload scanning engine, this is how HTTP uploads work. | ||
| + | |||
| + | For example, if an attacker attempts to upload a file to the application "/foo.php", and "/foo.php" does not exist, it is the client that makes the full request, with the payload (the upload) to the server, and server has to accept the whole thing to process it. | ||
| + | |||
| + | When a client tries to upload a file, it sends the entire request to the server. The server accepts the entire request, buffers it, then based on its configuration hands it off to the handler. For example, if the server is configured to handle PHP extensions with mod_php, it will then hand off the buffered request to mod_php. mod_php then decides what to do with the request. If the file/application does not exist, the handler, mod_php in this case, returns an error and Apache returns the 404. the module might also send 404s to a generic application, or perhaps another module, mod_redirect, would handle that. | ||
| + | |||
| + | During this time, however, the web server has already accepted the file and has buffered it somewhere (memory, or disk depending on the systems configuration). The malicious upload scanner intercepts the file when its received by the web server, not after the handlers have decided what to do with. This is by design, otherwise the file would have to be sent to the handler, and would have been processed before it was scanned, defeating the purpose of blocking the malicious upload. | ||
| + | |||
| + | Therefore its normal and correct behavior to see an attempt to upload a file via a web application that may, or may not exist. The existence of the application has no bearing on the scanning process, because the existance of the application is not something the web server checks until later in the process, when it would be too late to block the upload. | ||
Revision as of 12:05, 18 September 2012
Rule ID
351000
Status
Active rule currently published.
Alert Message
Atomicorp.com Upload Malware Scanner: Malicious File upload attempt detected and blocked
Description
This rule use the ASL malicious upload scanning engine. This rule will trigger if the malicious upload scanning engine detects that a user attempted to upload a potentially malicious file.
False Positives
The rule itself can not generate a false positive, however it is possible that the malicious upload scanning engine may have a signature that is incorrectly labeling a non-malicious file as malicious.
If you believe you have a false positive, do not disable this rule. That will disable the malicious upload scanning engine for all web uploads.
Please send us the file if you believe it is not malicious, and be sure to put a password on the file so it is not stopped by any antivirus or antimalware software.
Tuning Guidance
None.
Similar Rules
None.
Knowledge Base Articles
None.
Outside References
None.
Notes
File uploads in web servers occur before other modules are processed. This is because the web server has to accept the full request from the client, parse it, and then decide how to handle it. This is not a bug in the web server, or the upload scanning engine, this is how HTTP uploads work.
For example, if an attacker attempts to upload a file to the application "/foo.php", and "/foo.php" does not exist, it is the client that makes the full request, with the payload (the upload) to the server, and server has to accept the whole thing to process it.
When a client tries to upload a file, it sends the entire request to the server. The server accepts the entire request, buffers it, then based on its configuration hands it off to the handler. For example, if the server is configured to handle PHP extensions with mod_php, it will then hand off the buffered request to mod_php. mod_php then decides what to do with the request. If the file/application does not exist, the handler, mod_php in this case, returns an error and Apache returns the 404. the module might also send 404s to a generic application, or perhaps another module, mod_redirect, would handle that.
During this time, however, the web server has already accepted the file and has buffered it somewhere (memory, or disk depending on the systems configuration). The malicious upload scanner intercepts the file when its received by the web server, not after the handlers have decided what to do with. This is by design, otherwise the file would have to be sent to the handler, and would have been processed before it was scanned, defeating the purpose of blocking the malicious upload.
Therefore its normal and correct behavior to see an attempt to upload a file via a web application that may, or may not exist. The existence of the application has no bearing on the scanning process, because the existance of the application is not something the web server checks until later in the process, when it would be too late to block the upload.
