Cornelius Bergen

Hi milton-01,

This is very helpful. It seems Sucuri’s scanner has spotted some code in that file that matches their definition of a specific type of malware. I know 100% that there’s no black-hat SEO malware in that file.

I’d suggest contacting Sucuri and asking them to confirm that that file does or does not have malware in it. If there is malware in it, it might be getting added automatically by another script on your server. If there isn’t, Sucuri might need to tweak their scanner a little bit to prevent false positives. Please let me know how it turns out.

I like the whitelist approach since anything other than a known static file should simply return ‘Forbidden’ which is, I think, a good response. With the SetHandler method, PHP files are actually downloaded.

The multiple extensions issue is very real though and should be addressed. I wonder if it would be worth trying to fix that issue closer to the web root rather than just the uploads folder. Here’s an old but relevant discussion:
https://core.trac.ww.wp.xz.cn/ticket/11122#comment:8

Maybe something like this should be recommended for the root .htaccess file (only if the server is deemed vulnerable)?…

<Files *>
  SetHandler default-handler
</Files>
<FilesMatch \.php$>
  SetHandler application/x-httpd-php
</FilesMatch>

This is untested as well. But if it works, I would prefer to leave the uploads directory fix as-is.

Thanks for the suggestion! I’ll be testing this on a vulnerable server and will definitely consider this for the next release.

Hi Viktor,

I don’t have immediate plans but I have been meaning to review the plugin again and see what I can add.

Hi atdblog,

Thanks for posting…

1. It’s very difficult to recommend a perfect permission setting. Start at the lowest recommended setting and if the plugin is not able to edit the file(s), then increase it. If one plugin can edit the file, all of them can so you should be able to find something that will work for any plugin. Just be aware that testing permissions could temporarily break your site if they’re set too low. Sorry, I can’t be too specific here.

2. The plugin has no cache. For the directory indexing, did you put that code in the web root htaccess file? Perhaps there is a Options +Indexes somewhere further down in that file or in another htaccess file in a parent directory of the plugin. You can test that you’ve actually disabled directory indexing by pointing your browser to a publicly accessible directory that does not have an index file in it – perhaps a directory in your theme folder. If you see a list of files, apache is still serving indexes, if you get a “forbidden” error, you’ve got indexing turned off. If you have disabled directory indexing and Gauntlet Security is still giving you a warning for that test, please let me know what type of warning it is.

Which issues do you still see regarding the log file block?

In the most recent version, I’ve added a check that ensures that not all salts are equal. That should account for most situations where the salts haven’t been added and should avoid any false positives.