← Back to context

Comment by IshKebab

2 months ago

Right but the case that is being imagined here is a site that perfectly sanitises * but somehow still allows SQL injection? I don't think so.

> Right but the case that is being imagined here is a site that perfectly sanitises * but somehow still allows SQL injection? I don't think so.

It could literally just reject anything with asterisks.

It doesn't even need to do anything perfectly, it just needs to do it enough to produce hurdles for you. Like blowing through the number of attempts you realistically have remaining.

  • You vastly underestimate the creativity of people that bypass imperfect sanitisers.

    • I think sanitizing is the wrong word in this context. That sounds as if the idea were to take the SQL, try to ensure it's valid and then run it. That approach is of course very risky and I'd never do that.

      No, my idea (as you can see from my post) is: parse the SQL, then check the resulting structure (that is basically a whitelisting process) and then turn the structure into SQL again. The last part is crucial, because it means that you have turned a whitelisted structure into SQL. Or in other words: even if some evil person found a bug and was able to convince the sql parser that everything is fine even though it is not, they would not be able to leverage that, because you are not actually running their SQL.

      Or to be more concrete: let's say the parser thinks that something is a comment, but the DMBS would actually run it as SQL - then that would be a problem if you jsut sanitize the SQL. But it's not a problem if you turn the SQL structure into SQL again, because your code to do that would just reject anything that it doesn't expect (and that definitely includes comments).

  • Hurdles mean nothing to a determined penetration tester. Unless you have watched one in action, or tried an exercise yourself against a hard target, it is likely to surprise you how little "hurdles" mean.