Understanding the the file uploads rule

Hi,

‘File upload attempt’ means it was blocked because the file upload option is set to “Disallow Uploads”. This blocks any upload sent from a multipart/form-data HTML/PHP form. In the firewall log, it will look like that line:

20/Jul/14 03:55:45  #2996125  critical     -  124.244.17.26    POST /wp-admin/admin-post.php - File upload attempt - [prepxkua.zip, 3,419 bytes]

If you need to receive files, you must set the option to “Allow uploads”. This can indeed expose your site, but only if you have a malicious (or vulnerable) upload form on your site. In the firewall log, successful uploads will look like this:

22/Jul/14 11:20:26  #5542073  upload       -  172.16.0.1       POST /sites/wordpress/test_form.php - Uploading file - [wp-test.php, 436 bytes]

In addition, you will see the total number of uploaded files on the NinjaFirewall dashboard widget.

There are 2 exceptions:
1. If you are logged in as the administrator, you can always upload, even if it is set to “Disallow Uploads”.
2. If debugging is enabled (“Firewall Options > Debugging mode”), you can upload but the log will display the “DEBUG_ON” string:

22/Jul/14 11:33:58  #0000000  DEBUG_ON     -  172.16.0.1       POST /sites/wordpress/test_form.php - File upload attempt - [wp-test.php, 236 bytes]

What would be interesting is to find out why your second site sent an attachment if the option is disabled. Because if you look at NinjaFirewall source code, you will see that right after writing the “File upload attempt” message, it blocks the request and exit right away.
Maybe some PHP error on that site ? Has it been hacked lately ? Can you try to enable PHP errors (Firewall Policies > Hide PHP notice & error messages > NO), then try to upload and check if you see any error?

Many thanks for getting back and for the clear explanation.

The sites both use the Contact Form 7 plugin (latest version), and are set to accept .doc .docx and .pdf files uploads only

Each time I’ve tried to test the uploads, I’ve been logged in as the administrator, so they have been passing through the firewall and leaving no log entry. When I tried again after logging out, the file never completes its upload to the contact form, and it is logged as:

critical – IP address – POST /index.php – File upload attempt

(I didn’t see any php error error message (set to show php errors, disallow uploads))

After allowing file uploads and uploading files when logged out, the log reads:

upload – IP address – POST /index.php – Uploading file

So that seems to be working correctly, and as you expected.

After installing the Ninja Firewall, I initially had the uploads set to allow, but about 2 weeks ago I saw the following entry in the log:

upload       -  85.9.75.148      POST /wp-admin/admin-post.php - Uploading file - [ylfyyvjc.zip, 3,421 bytes]

I checked the wp-admin folder, admin-post.php file, and scanned my site with several different (a decent) antivirus plugins, but found no changes to any of the files, or any trace of the ylfyyvjc.zip file. As a precaution I set the uploads to disallow, but as my business relies on .doc and .docx uploads this is clearly not practical, and I’m really pleased that you pointed out that logged in users are able to override the firewall rules, as I had been testing the uploads to the contact form while being logged in.

Upshot is that I will have to leave uploads set as allowed.

Your example is similar to the first one from my previous message: an attempt to upload a 3Kb ZIP file through the /wp-admin/admin-post.php script by a bot. Except that in my example, the uploads were disabled.

You were not hacked and the file was not uploaded, but this misunderstanding comes from the way PHP handles uploads:

1. if you send a file via a multipart/form-data form (just like any uploaded file) to a PHP script, PHP will accept it, store it into a temp folder on your server and will copy its temp name into the $_FILES[‘xxxxx’][‘tmp_name’] variable. This occurs even if your PHP script does not accept uploads.

2. NinjaFirewall will hook the request:
a. if you disabled uploads, it will reject it.
b. if you allowed uploads, it will accept it and forward it to the destination script (e.g. /wp-admin/admin-post.php).

3. Your script will get that file:
a. it will accept it and move it to the destination folder (or send it by email etc).
b. it will reject it or will do nothing because it is not supposed to handle uploads. PHP will delete the temp file upon exit.

In your case, it reached 1, then 2b and 3b.
That is the way PHP works with uploads and that’s confusing, for sure.
I don’t think there is any possibility for NinjaFirewall to detect what the destination script did with that file. I’ll have a look at it anyway.

You can re-enable uploads, that is fine, you were not hacked ??

That’s a excellent walk through of the php process for file uploads, which is clear and logical. I’m reassured to know that with the /wp-admin/admin-post.php script not being directed to handle uploads, the dodgy zip was rejected, and deleted from the temp file on logout.

Many thanks for your patience in explaining this process, and for the reassurance it has given me.

Viva Ninja Firewall, and all who sail with her!

This is now resolved