Difference between revisions of "WAF 351000"
m (ue) |
m |
||
| Line 42: | Line 42: | ||
'''Notes''' | '''Notes''' | ||
| − | File uploads in web servers occur before other modules are processed. | + | File uploads in web servers occur before other modules are processed. 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. |
| − | + | This is because the web server has to accept the full request from the client, then 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 user attempts to upload a file to the application "/foo.php", and "/foo.php" does not exist, the upload will still be scanned. This is because the client makes the full request to the server, with the payload (the upload), and the server has to accept the whole thing to process it. So an upload occurs no matter what with a web server, even if there is no application to accept it. | |
| − | + | How this works: | |
| − | + | When a client tries to upload a file, it sends a request to the server that includes the URI, as well as the payload (the upload). The server then accepts the entire request, including the upload, buffers it, then based on its configuration hands it off to one or more handlers to process the request. | |
| + | |||
| + | For example, if the server is configured to handle PHP extensions with mod_php, the web server will then hand off the buffered request to mod_php. mod_php then decides what to do with the request, and checks to see what application(s) to process the request. If the file/application does not exist, the handler, mod_php in this case, may return an error or it might do something else. If it returns an error, then the web server returns that error to the client. | ||
| + | |||
| + | 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), even if the application does not exist. 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 handlers, which may have their own vulnerabilities, and would have been processed before it was scanned, defeating the purpose of blocking the malicious upload. | ||
Revision as of 11:23, 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. 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.
This is because the web server has to accept the full request from the client, then 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 user attempts to upload a file to the application "/foo.php", and "/foo.php" does not exist, the upload will still be scanned. This is because the client makes the full request to the server, with the payload (the upload), and the server has to accept the whole thing to process it. So an upload occurs no matter what with a web server, even if there is no application to accept it.
How this works:
When a client tries to upload a file, it sends a request to the server that includes the URI, as well as the payload (the upload). The server then accepts the entire request, including the upload, buffers it, then based on its configuration hands it off to one or more handlers to process the request.
For example, if the server is configured to handle PHP extensions with mod_php, the web server will then hand off the buffered request to mod_php. mod_php then decides what to do with the request, and checks to see what application(s) to process the request. If the file/application does not exist, the handler, mod_php in this case, may return an error or it might do something else. If it returns an error, then the web server returns that error to the client.
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), even if the application does not exist. 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 handlers, which may have their own vulnerabilities, and would have been processed before it was scanned, defeating the purpose of blocking the malicious upload.
