WordPress Firewall 2 had an option to Whitelist Pages and/or Form Variables.
Enter page and/or form variables that are whitelisted — and not subject to security rules:
Page: Form Variable:
I don’t really need the Pages options, but I have to whitelist certain form variables like cookies that certain plugins create otherwise they’ll cause false positives for users.
It seems to be missing from your version. Is it possible that I missed it? Thanks.
Nope, you haven’t missed it. Currently I don’t take cookie variables into consideration in this version.
I’m still looking for a good reason to do that. Since it would be assumed that plugins placed on the site are “trusted” in the types of cookies they would be setting. I think I might offer this as a future option, but for now cookies are not counted just yet.
I also have yet to allow custom whitelisting of pages and variables… this will come in a future release. I’ve started with the core and gone from there. There’s more to come.
Thanks for the suggestion!
Installing this plugin would be a good reason.
It creates a cookie that could be mistaken as something malicious. It’s vary rare that it would happen but it does. It’s been so long since it has happened that I do not remember the exact string but it did happen several times.
Also I create a PHPSESSID cookie just to help keep the spammers away via my own construct and .htaccess. Since I use:
session.hash_bits_per_character = 6
it’s more complex with the possible characters (0-9, a-z, A-Z, “-“, “,”)
which has also been caught as well. It’s not the trust in the cookie that matters, but the string that is in the cookie value, etc. It’s random, so it’s possible it could look like an SQLi or something similar.
I maybe mistaken, but I’m under the assumption WordPress Firewall 2 just used $_GET and $_POST when checking for malicious strings. So if your plugin does the same, it will also catch false positives. It’s pretty much possible with anything, not just a cookie. So basically without being able to whitelist certain forms, users will have to disable, certain protection options. Seems like it would make better sense, to be able to whitelist a form or page then just to disable a certain option. At least then it would still provide some protection and keep down on any false positives and make the plugin useful.
Yep, you’re absolutely right… the ability to white-list certain pages and their parameters is important. It’s a little more complex though than IP whitelist so I went for getting functionality out first and taking feedback such as yours, before plowing down a path that no-one is looking for.
I’ll look to start adding that soon… it might not be in for a few weeks though.
(Also, WPF2 did actually include the Cookies in its processing.)
Stay tuned and hopefully I’ll get the whitelisting for pages/form in sooner rather than later.
Thanks for the feedback!
Thanks for the replies. That’s good to know as I have friends that would like to use your plugin, but they may have issues with it in it’s current state, that’s why I asked (they asked me about it). Thanks for considering whitelisting as option as I’m sure many others will appreciate the option as well. 🙂
Alright, this is done. The FAQs layout how it works.
It’s basically a list of comma separated pages and parameters. Each new line is a new page and then you supply the paramaters for the page with comma-separate values.
If you use a * for the first value in the line – the page name – then it counts for all pages.
Let me know what you think.
Sweet, that was fast. One thing though. I was trying to test to see if it works before whitelising anything (IPs, pages, parameters, etc). So nothing is whitelisted, not even myself. I tried an SQLi on the comment form and nothing happened. Where as with WordPress Firewall 2 it blocked it as it has in the past.
I have the following set:
WordPress Firewall Options
Completely turn on/off the firewall CHECKED
Turn on a detailed Firewall Log UNCHECKED
Choose Firewall Block Response
Choose how the firewall responds when it blocks a request Redirect To Home Page
When a visitor is blocked it will send an email to the blog admin UNCHECKED
Where to send email reports BLANK
Whitelist – IPs, Pages, Parameters, and Users that by-pass the Firewall
Choose IP Addresses that are never subjected to Firewall Rules none
Detail pages and parameters that are whitelisted (ignored) BLANK
Ignore users logged in as Administrator UNCHECKED
Choose IP Addresses To Blacklist
Choose IP Addresses that are always blocked access to the site none
Firewall Blocking Options
Block WP Login Access UNCHECKED
Block Directory Traversals CHECKED
Block SQL Queries CHECKED
Block WordPress Specific Terms CHECKED
Block Field Truncation Attacks CHECKED
Block Executable File Uploads CHECKED
Block Leading Schemas (HTTPS / HTTP) UNCHECKED
Miscellaneous Plugin Options
Delete All Plugin Setting Upon Plugin Deactivation UNCHECKED
Can you give me an example of the query you called that didn’t work?
I looked through the WPF2 plugin and my own and they (as I) have whitelisted automatically the URL and the Comment fields in the wp-comments-post.php pages.
So I’m wondering what WPF2 would have been picking up in this case since they’ve whitelisted those fields.
I’d be interested to see the example text you have posted.
Then I may have been partly incorrect. I believe I was a editing a cookie on that page that had a comment form at the same time I was trying on the comment form. I had to disable so much stuff to test, that I’ll have to try again later (I use multiple things to protect against SQLi). But even if I changed the cookie to match an SQLi, WordPress Firewall 2 caught it when I went ventured anywhere, where your plugin didn’t.
I just tested with these:
concat( group_concat unionselect
I may add the option then to check cookies also… currently this isn’t the case.
Alright, I’ve just added the option now to check cookies in v1.1.6
Great. I believe all of the people using WordPress as an e-commerce site will greatly appreciate it. I’ll try to test the latest version in a couple of days or so.
I’ve confirmed that it blocks when SQL is used in a cookie field and that whitelisting works as well. Thanks for the update.
If you use the Anti-Captcha plugin you would have to whitelist it like so if you allow comments all over your site.
For your troubles I would like to return the favor by offering you a more efficient .htaccess file that you have now included.
This one is more efficient. Does basically the same, but whitelists from the beginning, where yours was blacklisting than whitelisting.
Order Allow,Deny <FilesMatch "^.*\.(css|js|png)$"> Allow from all </FilesMatch>
That Order Directive means if it doesn’t match Allow or Deny, it is denied. Since it says to only allow those specific file extensions, everything else is denied.
Ahh, awesome, thanks for the updated .htaccess – I’ll include that in the next release. Cheers!
And huge thanks for the 5* review… appreciate that too.
Glad we got the plugin to a place where you like it to use it and recommend it… I call that a success! 🙂
- The topic ‘Whitelisted Pages and/or Form Variables?’ is closed to new replies.