Support » Plugin: BulletProof Security » [Plugin: BulletProof Security] Problem with search

  • Resolved mihai.todor85



    I consider this a good plugin, but it still has certain bugs which need to be ironed out. One of them is that it breaks the WordPress search feature for certain queries.

    Try to search your blog for “richard”, for example, with the secure.htaccess enabled.

    This breaks because of the way too general regex conditions from these two statements:

    RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
    RewriteCond %{QUERY_STRING} ^.*(execute|exec|sp_executesql|request|select|insert|union|declare|drop|delete|create|alter|update|order|char|set|cast|convert|meta|script|truncate).* [NC]

    I know there must be a better sollution, using lookahead, but I do not yet master regex that well, so I propose this quick fix:

    RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
    RewriteCond %{QUERY_STRING} ^.*(execute|exec|sp_executesql|request|select|insert|union|declare|drop|delete|create|alter|update|order|char|set|cast|convert|meta|script|truncate).* [NC]
    RewriteCond %{QUERY_STRING} !^s\=.*$ [NC]

    I am aware that adding this condition might help some hacker achieve his purpose, so I hope that someone else can suggest a better one.

    Also, there are a few other regex conditions with which I do not agree:

    1. This one is way too general:

    RewriteCond %{REQUEST_FILENAME} ^(.*)thumb(.*)$ [NC]
    RewriteRule ^(.*)$ - [S=30]

    2. If you have access to edit files, you probably have access to edit the database, so I suggest keeping password reset features disabled:

    # Login Plugins Password Reset And Redirect Conflicts Fix 1
    RewriteCond %{QUERY_STRING} action=resetpass&key=(.*) [NC]
    RewriteRule . - [S=30]
    # Login Plugins Password Reset And Redirect Conflicts Fix 2
    RewriteCond %{QUERY_STRING} action=rp&key=(.*) [NC]
    RewriteRule . - [S=30]

    3. Regarding the wpadmin-secure.htaccess, why does it not generate a 404 when I try to use the search feature in the admin just like id does in the front end? Is it just my impression, or those “QUERY STRING EXPLOITS” in it are being ignored? I do not have the time to investigate this any further, but please look into it.

    One more thing I forgot to mention: check out this query (It’s not my blog, I’m just the administrator). It breaks, as it should, but instead of redirecting to the site’s custom 404 page, it goes straight to that Apache test page. I think this is because of the “forced redirect” generated by the minus:
    RewriteRule ^(.*)$ - [F,L]
    Isn’t there a gentler way to do this (even if hackers don’t deserve it)? 🙂

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author AITpro


    That is the beauty of BPS – you are not confined or restricted to using any preset or predetermined htaccess coding. You can create whatever you need for your particular needs and requirements with the built-in File Editor. The htaccess coding that is currently in BPS is designed to work for the most common WordPress setup. It would be a monumental and probably impossible task to try and calculate every possible setup variation that could exist so this is not something that i would ever attempt to try and do. I have provided the base htaccess coding that should work fine for everyone without having to modify anything, but there is so much more anyone can add to their own custom master htaccess files that it would take several pages to list all of that info.

    On points 1 and 2 I tested whether or not external hacking attempts could manipulate or exploit these exceptions with various hacking methods and I did not find any security vulnerabilities, but if you know of one please let me know.
    Logically if you could make (spoof) a request to look like is was coming from an internal source then an exploit could be done, but I was unable to successfully hack or exploit either of these exceptions myself with every hacking script i have in my collection.

    “2. If you have access to edit files, you probably have access to edit the database, so I suggest keeping password reset features disabled:”

    I don’t exactly understand what you are saying or thinking on point 2? The htaccess skip rule will only work with internal script processing so maybe you are thinking that these could be exploited from an external source? You would have to somehow spoof the http referrer, which in itself is not that difficult to do, but there is another factor that i don’t want to mention that will ultimately prevent the spoof from working.

    3. You would need to add additional htaccess coding to the wpadmin-secure.htaccess file in order to do that. USE CAUTION – No URL rewriting should be occuring for the wp-admin folder or you WILL break your admin area.

    If you have not added ErrorDocument directives to your htaccess files then 404’s and 403’s will default to whatever your web hosts 403 and 404 pages are. The query should redirect to a 403 page not a 404 page because it contains the word “select” which is an SQL command that is filtered out in the SQL Injection filters. As i said before nothing is set in stone with BPS that is why i built the File Editor first and added automagic almost an entire year later. The idea is you can create whatever custom things you want for your particular site or if you just want to use what is already available it should work in probably 95% of all cases without any additional modifications being necessary. Thanks.


    Don’t get me wrong, but I just wanted to start a discussion regarding certain parts of the module with which I do not agree 100%. Like I said, I consider this a good plugin, but like all things, nothing is perfect 🙂

    Now, regarding 2: Well, call me paranoia, but I consider that password resets should not be done from the admin interface at all. There should be an option to disable it. I do not actually care how hackable or unhackable this thing is (remember that bug in 2.8.3 which allowed anybody to reset your admin password with a special URL query? Although mostly harmless, it was annoying as hell)

    3. I do not think I understood how this works or why does it not block an admin search in posts for the word select, for example, but at the moment, I do not have time to investigate. I know that no URL rewrites are used for the admin (d’oh, it’s pointless).

    Regarding the error documents, I suppose you are right, and it is a local configuration problem. I will try to fiddle around with the ErrorDocument directives again, but I have a feeling that I’ll end up cursing Plesk like last time.

    Thank you very much for your explanations.

    Best regards,

    Plugin Author AITpro


    Cool and nope i didn’t get you wrong at all. Like i said anyone can do anything they want with BPS. I have created a completed plugin (with room to grow always) that can be custom tailored by each person for their individual needs. I’ve already put in 1,000’s of hours so far in research, testing, coding, support, etc etc etc and will continue to develope BPS further whenever i have spare time.

    I think the majority of people are using an emailed password reset feature. Only a handful of people have contacted me regarding an insite password reset feature so it really is kind of an additional thing just for those people who are using that. Personally i don’t use this because of the potential added security risks involved. So if someone is not using this then whether or not the htaccess code exists is a moot point. The code can either be removed or left alone because it isn’t doing anything if someone is not using an insite password reset feature. And the htaccess code that is there is a skip rule so BPS is not protecting insite password reset plugins that are using these strings. The security protection of those plugins should be in the coding in whatever plugin or other coding they are using. If someone wants to take that extra risk of using an insite password reset then it is up to them to decide that – BPS just gets out of the way and will no longer block those strings if they are being used.

    Well without going all technical on you i can just reassure you that .htaccess files are designed to block external scripts from executing against your website and other external threats, while htaccess also allows internal things to function normally otherwise your site would not load at all if the directives in the htaccess files were applied to and filtering all your internal functions, etc.

    I am not a real big fan of Plesk myself. In Plesk’s defense they have tried to simplify something that is fairly complex with a nice simple GUI that everyone can understand.

    ErrorDocument directives are pretty straightforward.

    ErrorDocument 403 /path-to-file/403-error-document-filename
    ErrorDocument 404 /path-to-file/404-error-document-filename

    … and most themes have a 404.php template so if you point to that file with ErrorDocument then the 404 template loads internally within your site instead of a separate 404 page. And since your Theme folder is considered a virtual root then you would just add this if your Theme 404 template was named 404.php

    ErrorDocument 404 /404.php

    or for a subfolder WordPress site where WordPress was installed in a folder called “MyBlog”

    ErrorDocument 404 /MyBlog/404.php


    Thank you very much for this explanation. I’ll get back to you if I’ll have any more questions.

    Have a good day,

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘[Plugin: BulletProof Security] Problem with search’ is closed to new replies.