Care to elaborate with something specific?
Hi @jeff,
It’s simple. The plugin doesn’t control POST variables and it’s too easy skip firewall’s protection over GET variables. Try adding this string to an existing entry of your blog (with permalinks disabled)
string = %20%75%6E%69%6F%6E%2B%61%6C%6C%2B%73%65%6C%65%63%74
Does BBQ control the attack?
Thanks, I will look closer at filtering POST requests for the next plugin update. In the meantime, the following GET request:
%20%75%6E%69%6F%6E%2B%61%6C%6C%2B%73%65%6C%65%63%74
is simply the encoded equivalent of “union+all+select”, which is a legitimate string that should not be blocked (think search queries, for example).
If you have an example that demonstrates some sort of real threat, please share. Otherwise, I think your accusation of “false security sensation” is unfair. BBQ continues to protect against a wide range of potential threats and malicious requests.
Hi @jeff,
you say:
[..] which is a legitimate string that should not be blocked [..]
If I look at your code, line 23, I found:
$request_uri_array = apply_filters('request_uri_items', array('eval\(', 'UNION(.*)SELECT'
Below, in line 38:
if ( preg_match( '/' . implode( '|', $request_uri_array ) . '/i', $request_uri_string ) ||
and inline 41:
) {
bbq_response();
}
Are you telling me that string “UNION ALL SELECT” is an allowed string? Your code says other thing. With the example I’m trying to show that pattern search has problems with encoded string and language encodings.
I don’t try to despise your work at all, all work on security is great, but you should be more strict on plugins’s description ( the sentence: “Scans all incoming traffic and blocks bad requests” is not true )
Regards and don’t let that my opinion stops your work
I think there is some confusion here.. when the plugin says:
“Scans all incoming traffic and blocks bad requests”
..it definitely does that, as you can verify by examining the code. What that means is that every request is checked, and bad requests are blocked.
Of course this doesn’t mean that every request is blocked, which seems to be what you are suggesting. It also doesn’t mean that every bad request is blocked; that simply is not possible using any script or plugin.
Hi @jeff,
that is you opinion, I have another one. Good luck with code.
Regards.
PD. congratulations for your quick responses and your effort
I mark this topic as resolved.
Oh really? You know of a plugin or script that blocks all bad requests? If so, please enlighten us with the information 😉
It simply is not possible. I defy you to prove otherwise.
As you say, It’s impossible to protect from every possible attacks. But there are scripts better than other doing this job. For example, Do you know PHPIDS? What do you thing about it? Does PHPIDS protect better than BBQ? Try it and tell me.
https://github.com/PHPIDS/PHPIDS
Regards.
“As you say, It’s impossible to protect from every possible attacks.”
Bingo. Each plugin or script provides its own level of protection based on a variety of factors including target vector(s), users, cost, region, platform, etc. These factors vary substantially, which is why there are so many security plugins and scripts available. Each script protects against a specific set of threats, for a specific platform, for a specific user base. So your example of PHPIDS may protect against certain threats for PHP-based applications, it does nothing for other applications. Likewise for WP plugins: they protect WP sites, not Joomla sites. And so forth. It’s much more complex and nuanced than what you are suggesting here. Some scripts excel at blocking “x”, others are good at protecting against “y”, and yet others may help stop attacks from “z”, et al.
If you have a favorite/preferred security application, then great. Go tell the world about it. But please try to show some class and avoid posting unfounded, unfair statements about plugins that you don’t use or prefer. BBQ and BBQ Pro both provide solid firewall protection for WP-powered sites, as over 50K users will attest.
