Support » Plugin: BulletProof Security » [Plugin: BulletProof Security] Security hole discovered

  • Resolved mihai.todor85



    Although I could be mistaking, I think I found a big security hole in the protection this plugin is supposed to provide.

    Basically, after you setup the “secure.htaccess”, if you try to perform this query:
    it will throw you to the big, bad 404 page.

    Now, in case you are using wordpress permalinks (most people do) try to perform this query:
    and notice that it does not redirect you to the 404 page anymore…

    Why? Because the wordpress standard htaccess code:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    # END WordPress

    is performed before all the security rules and, in case it performs an “Internal Redirect”, like in the above example, as far as I can see, it skips all the rules below.

    If I am not mistaking, this can be fixed by placing this standard WP htaccess code below the security redirect rules, but I’m not sure if it does not break anything else, so I hope the plugin author can confirm or infirm it.

    Oh, one more thing which still annoys me: why doesn’t the secure htaccess for wp-admin block this query:
    I mean, this should be it’s purpose, right?

    Best regards,

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


    Yep you are mistaken. 😉 This is not a security hole, vulnerability, flaw or problem. The test is only a test and does not really apply to how the .htaccess file security / directives work. It just so happens that you can test the SQL Injection filtered commands by entering them directly into your root URL. This is just for testing. the same applies to when you add a SQL Injection filtered command in your search window. You will see instant test results that your root htaccess file is working, but this has very little relativity to how the htaccess directives would be applied in a real hacking attempt – once again this is only for basic testing to ensure that your root htaccess file is set up correctly on your site and that is all this test does. If you want an accurate test of how the BPS SQL Injection filters work than google an SQL Injection hackers script and then try to run it on your website – this would be an accurate test of how the htaccess directives / rules work in a real hacking attempt.

    A directive condition is a condition and it is processed if that condition is found. The manual URL test is throwing you off and is not an accurate test of the conditions – it is only an accurate test that your root htaccess file conditions are being seen. The test is not an accurate test of the conditions themselves in a real hacking attempt.

    I have appreciated your input in this post and your other posts, but I myself am getting pretty annoyed with you asking about the wp-admin htaccess file over and over. Instead of asking me to explain how the basics of htaccess works in general why don’t you do some research first on how htaccess security works then once you have a basic understanding of htaccess security then i think a lot of your questions will be answered without me having to explain htaccess 101 to you. I hope this statement is not taken the wrong way. It is not intended to offend or belittle you, but before I start explaining htaccess basics to you i need to know that you have some basic understanding of how htaccess security works.

    This may be helpful to you in understanding how the entire block of Query String Exploits filters / conditions works together. If you understand PHP coding then this should be pretty easy for you to grasp. A function in php typically has conditions ie – if this, else this, and this, or this, etc. In order for a real SQL Injection hacking attempt to be successful then it would need to “get through” at least any 2 sets of conditions in the Query String Exploits filters. They work together like a single function blocking conditional statements made by the hacking script and conditions can also work independently in basic tests. Once again in order to accurately test how BPS blocks actual hacking attempts you would need to use a real hacking script. The basic URL test is just that – a simple test to show that your root .htaccess file is being seen correctly. Find either XSS, SQL Injection or whatever other type of hacking script you choose to test against BPS to get an accurate test of how the Query String Exploits filters / conditions work together to block any and all hacking scripts. Thanks.


    Hello Ed,

    As before, I was hoping for a more productive conversation with you, but all I find is the fact that you are trying very hard to make your product seem perfect. I know that it helps and it adds a lot of protection, but my experience tells me that it can be improved.

    I am not set on trashing the countless hours of the work you invested in writing it, but you do not seem to understand this. Actually, this is how open source code ends up being of higher quality than closed source: by getting constantly reviewed by many different programmers who work in many different environments.

    I also realize now that you have a brand to protect, and this type of conversations won’t make you look good to people who think that by using your plugin cannot be hacked. You probably earn some money from this as well, don’t you? If this is the case, you could have simply asked me to use email to report problems. You have my permission to remove all of my posts concerning your plugin, if they bother or offend you.

    Actually, I’m hoping that your first and last paragraphs are meant as a joke, since only “script kiddies” would use only known and standard scripts found via Google to hack something. Professionals have a tendency to mutate them 😉

    There is no need to mock me or to call me a n00b in an elegant manner. I have more than a few years of experience in the industry and, although I am not an Apache or security expert, I know my way around code and I can use a debugger quite well (RewriteLog & RewriteLogLevel).

    Keep up the good work on building plugins and please don’t bother answering. You will not receive any more comments from me. Ever.

    Have a good day,

    Plugin Author AITpro


    Cool we are in agreement then. All conversation between us should cease permanently. Thank you.

    Plugin Author AITpro


    And of course I feel terrible about snapping because I am not a jerk, but I don’t like coming across Google results like this one Title “BulletProof Security Security hole discovered”. Grr. It bugs me a little bit even though I know that most people will actually click on the link and read the info to see what is up. Any way now that the steam has stopped rising off my brain. This is basically how htaccess Rulesets are processed. This is verbatim from the Apache site.

    Ruleset Processing
    Now when mod_rewrite is triggered in these two API phases, it reads the configured rulesets from its configuration structure (which itself was either created on startup for per-server context or during the directory walk of the Apache kernel for per-directory context). Then the URL rewriting engine is started with the contained ruleset (one or more rules together with their conditions). The operation of the URL rewriting engine itself is exactly the same for both configuration contexts. Only the final result processing is different.
    The order of rules in the ruleset is important because the rewriting engine processes them in a special (and not very obvious) order. The rule is this: The rewriting engine loops through the ruleset rule by rule (RewriteRule directives) and when a particular rule matches it optionally loops through existing corresponding conditions (RewriteCond directives). For historical reasons the conditions are given first, and so the control flow is a little bit long-winded. See Figure 1 for more details.

    As you can see, first the URL is matched against the Pattern of each rule. When it fails mod_rewrite immediately stops processing this rule and continues with the next rule. If the Pattern matches, mod_rewrite looks for corresponding rule conditions. If none are present, it just substitutes the URL with a new value which is constructed from the string Substitution and goes on with its rule-looping. But if conditions exist, it starts an inner loop for processing them in the order that they are listed. For conditions the logic is different: we don’t match a pattern against the current URL. Instead we first create a string TestString by expanding variables, back-references, map lookups, etc. and then we try to match CondPattern against it. If the pattern doesn’t match, the complete set of conditions and the corresponding rule fails. If the pattern matches, then the next condition is processed until no more conditions are available. If all conditions match, processing is continued with the substitution of the URL with Substitution.

    Any way I apologize for snapping at you, but in the future please consider the impact of your statements before posting such a potentially damaging statement.

    And dude this is a free plugin. Yeah i think I’ve made $300 in donations, but I’ve put in well over 1,000 hours of my time. I charge around $40 an hour for website design and other things so even a low estimate on the hours i have put in is $40,000 worth of my time. So it looks like my total take on the BPS project is minus $39,700. Not a very profitable endeavor. LOL Luckily i have some sweet clients that take care of me because I put them on top, but otherwise i would not be able to afford to donate my time like this and take on such a time consuming and expensive hobby. Thanks.


    Working with code basically equates to being subjected to ‘bend over, because we don’t understand it, but we want to show you that we know best. And, actually, I suspect I don’t really need you anyway, because it’s pretty easy, right?’ on a regular basis.

    It’s tempting to quote Morrissey ala Joey Barton. Maybe ‘Orange Juice’, ‘Simply Thrilled Honey’ would be more apt (I choose to leave myself of tired little fears – To stand as one against the all too obvious rising sun)?

    It’s easy to think that if you contribute to WordPress and open source for free, that people would appreciate it. It’s also loads easier to lash out at someone else’s protagonist. I feel much better, thanks!

    Also, if someone is a plonker, there’s not much you can do to change that – even if you do call them that in an elegant manner. It’s nice to see that he’s committed to never contacting you again though.

    I’ve found the plugin very useful, thank you. You can delete this if it’s too blue, I won’t take it personally!

    Plugin Author AITpro


    AWESOME!!! I needed a good laugh and this had me laughing hysterically! And no on the contrary it is not too blue – I just bookmarked this page with the Title “when you need a laugh and a reminder of how it really is”.

    Yeah I never should have vented in the first place, but this was only after several posts by him and I agree with him that things can always be improved on and collaboration is important and necessary for growth.

    No one person can usually think of or see everthing so a group effort usually results in a much better outcome. Maybe I was interpreting his languaging or approach incorrectly, but i kept rereading his comments and each time i came to the same conclusion. That his true intentions were to make BPS look bad and to make people worry about using and trusting BPS. But i could be totally wrong and he is just simply not a diplomatic type of person. 😉 Thanks for this awesome comment man! Have a great one!

    Collaboration is definitely the backbone of open source, as is (or should be) compassion – hopefully, one day, my code will be good enough to contribute to WordPress – but in the meantime, I’ll rely on the people who are willing to put the time in 🙂

    I have used your plugin on 1 paid site and 3 unpaid sites and it worked wonderfully, without a hitch – if I knew, or could be bothered to find out enough about the .htaccess files or write access then i wouldn’t need the plugin. I don’t think I need to say that if I was a PHP master I wouldn’t need plugins – or feel compelled to needlessly complain about them.

    To the OP:
    You have not discovered a security hole – as was explained nicely. Actually read the apache directive that was linked to.
    This thread serves no useful purpose…so it’s now closed.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘[Plugin: BulletProof Security] Security hole discovered’ is closed to new replies.