The plugin doesn’t block SQL Injections ?

In the meantime i did several other “attacks” for sql injection to my site and none has been blocked or logged.

Is there a particular sql injection vulnerability you’re targeting here? I’d like to understand more of the particular nature of the “attacks” you’re referring to.

Putting text in a query string that could be interpreted to adhere to SQL syntax does not make it an sql injection. There are some patterns in the plugin to catch certain SQL keywords, but in principle there is no reason to block the above query in and of itself.

It would be great if you could elaborate further and also demonstrate what injections you’ve been able to achieve. If it’s more appropriate, and it may well be, please feel free to emails directly, rather than posting it here.

Paul, how can i test if your plugin protects against SQL injections ?

And if what you say above is correct (probably so) why other firewall plugins or wrappers catch all those attempts as SQL injections.

Thanks

The first thing I’d say is that we don’t take our cues from the other security plugins… if they feel that this constitutes an SQL injection, we don’t necessarily agree. We are always open of course to adding and adjusting the firewall rules to encompass more scenarios.

As to how to test sql injections, a quick Google search will lead you to demonstrations on how these work and how you can attempt it. If you are able to achieve this with a WordPress site while using Shield then I’d really like to know about it.

In the meantime I’ll review our rule-set to see if there is anything we can tighten up. Cheers!

Searching Google made me doing all those tests.

And can’t all other plugins or Mod_Security rules (Comodo WAF) be wrong.

Anyway, still unclear if this plugin works 100%.

I’m not suggesting that they’re wrong. Not at all. But I’m saying we don’t try to keep up with all the other plugins because “if everyone else does it then they must be right”.

As I said, we’re happy to review and adjust, and we may have improvements to make and perhaps we should be filtering those sorts of parameters. We don’t know yet. But I’m not going to line up behind everyone else because everyone else is lining up. We’ll assess it and take the necessary steps.

An example: lots of other plugins maintain large lists of IP addresses to block. They all do it, so why don’t we? Because it make no sense whatsoever.

We’ll continue to review, adjust and adapt. If this doesn’t inspire you with the necessary confidence, then I’m sorry to hear that. But it’s this approach that has set us apart from many others and why many clients like the plugin.

The reality is that if you feel Shield isn’t doing a good enough job, then that’s perfectly okay. As you say, there are other plugins out there doing the things out there you want them to, so perhaps they’re the better choice for you in this case. I think we should all use the tools and services that suit our needs. I see no issue in that whatsoever.

Well, my question was only for SQL attacks and i got no real reply. Or maybe i got the reply that Shield plugin is not very sentitive and only blocks real attacks. Still i have no test file or url to test that claim.

For the rest you write, since i really like the plugin and i will continue to use it everywhere, i think they are irrelevent.

Thanks again.

We’ve reviewed some of the information on sql injections and added 2 more new rules to the Shield scheduled for the next release.

It’s important to understand the ability to block sql injections and blocking what might appears to be attempts at an sql injection.

The former requires that there is an sql injection vulnerability, known or otherwise. The generic rules that various plugins use to block SQLi are generic, and can only ever be generic in the hopes of catching broadspectrum/brute force attacks. The pattern you suggested in the original post is just 1 example of that but does not of itself represent an SQLi.

We are cautious about implementing generic rules that are too strict. Our newer rules will be placed in the “aggressive” filters section upon release because they could legitimately catch false positives.

My response to your post was whether you can demonstrate a successful SQLi with Shield in-place. Then we’d have something to formulate a plan from. A lot of security is about adaptation on both sides.

But posting the tail-end of a part of a potential SQLi doesn’t in itself make for Shield to be incapable of handling the issue. And frankly, no plugin can cater for all of those.

As an aside, your post gave me a new idea as an extension to the transgressions system – soft fails. I.e. transgressions that don’t trigger a block, but enough soft transgressions will ultimately lead to a block. It’s something I’m pondering and would be a nice addition to the system.

Thanks again for your feedback.

Thanks for the update information.

So, let’s assume that Shield plugin blocked totally the url i posted in the start.

Question: Why someone tries to access a url like that ?

So what is the harm done if blocked ?

• This reply was modified 7 years, 7 months ago by massimod.