in reply to SQL Injection myths under DBI?

I consider this abysmally stupid advice and am moderately depressed that people have actually voted you up for it.

First of all you decided that you'd only worry about a '. But the substiution that you provide is beatable by having \'. Now you substitute it into \\', which is read as \ followed by an unescaped '. Oops.

Just to pick another random item you overlooked, what about a null byte? If the driver interfaces with a C library, many will terminate what they think is the string when they see a null byte. So someone can break out of a string, insert code, and terminate the SQL statement prematurely. Not a good idea.

In any case when it comes to security it is not enough to hope that things will work out OK. You have to be paranoid. Just because you can't see the exploit doesn't mean that it isn't there. Pre-emptively remove the possibility of being exploited and maybe that will be enough. Then a new class of exploits get discovered and you can get all worried again.

Replies are listed 'Best First'.
Re^2: SQL Injection myths under DBI
by itub (Priest) on Apr 12, 2005 at 13:59 UTC
    I upvoted him even if I don't entirely agree because I think this is a good debate to be had. I tried some of this stuff myself a few months ago, and was surprised that the typical sample SQL injection attacks you see advertised didn't work (on my database and dbd) because it didn't execute multiple statements. What may be different is that, even after noticing that I decided to keep using placeholders, for the same reasons others have cited in this thread.

    In other words, I think it's good that the OP tried to figure out how things work, but I think one should be wary of extrapolating this too far and reach the conclusion that SQL injection is "impossible".

      While I agree that it is good to try these things for yourself, I objected to his very wrong conclusion.
Re^2: SQL Injection myths under DBI
by Andre_br (Pilgrim) on Apr 12, 2005 at 05:45 UTC
    My dear tilly,

    Please take a look at my last post, regarding the point you mentioned (that was already mentioned 2 times by other friends of ours).

    Regarding null-byte, please explain how can I receive this through CGI.

    Regarding the judgement you´ve made, "abysmally stupid advice", please, my friend, this is not the place to be this rude. This is not behaviour for a monk!

    André

      It has already been pointed out that null bytes can be passed through CGI. This is an idea that has been successfully applied to attacking CGI scripts that make shell commands.

      There are other tricks to use as well. For instance rather than try to get multiple SQL statements in there, you can put subqueries in. Like this:

      \' or exists (delete from tblusers) or --
      with -- attempting to use a more traditional comment to hide the closing '. It is likely that you'd need to try several variants of this to get something that would work, and it is possible that your database is immune. That doesn't mean that depending on that immunity is OK though, because you may continue to think that you are immune when you switch to a different database. In IIS with common configuration mistakes, for instance, a subquery like this can launch a remote shell giving you direct access to the database machine. Furthermore a later rev of your current database may add features that are currently missing - and you are no longer immune.

      As for the perceived rudeness, I see two good options for you. The first is to regard me as a friend who cares enough to tell you honestly when you are making a terrible mistake. The second is to regard me as a not-friend who is warning other people that he might care about about how awful your advice is because he doesn't want to see them get hurt.

      I'm willing to make either option become true.

      In any case I didn't say that you are abysmally stupid, just that your advice was. And it really was, you are approaching security from exactly the wrong direction. Rather than say, "I couldn't figure out how to break this, I must be OK" you need to say, "I can guarantee that this is correct." Because even if you can't figure out the trick needed to make the attack work, that is no guarantee that some attacker out there who does this all of the time (rather than just takes a day or 2 to try to get it to work) won't know some trick that you didn't think of to get this to work. Open source provides a good demonstration. There is no shortage of cases where good, experienced programmers have looked at a programming mistake in open source code and proclaimed, "OK, this is bad but I don't think it is exploitable" only to find that shortly afterwards someone has figured out how to exploit it and the exploit is in the wild.

      In short, if you catch yourself thinking, "Despite knowing that this is supposed to be bad, I think that this is OK because I don't see how an attacker would attack it" you're on the wrong path. You are opening yourself up to a game of wits that you might lose and is at best a draw for you. Why play that game? If you can easily guarantee safety, there is every reason to do so and no reason not to.

      Regarding null-byte, please explain how can I receive this through CGI.

      Easy:

      scipt.cgi?name=admin'%00

      Regarding the judgement you´ve made, "abysmally stupid advice", please, my friend, this is not the place to be this rude. This is not behaviour for a monk!

      Well, I think it is stupid advice :-) I'm not trying to be rude, and I'm not saying that you are stupid. You're quite right in questioning something that you see as cargo-cult programming. It's just that you are advocating ignoring something that is potentially dangerous without knowing the full scale of the problem.

      Insults aside, tilly makes a good point here.
      You conclude that ONLY the ' is a problem because you could not find a problem with any other character/sequence.
      Now if anyone else finds a problem with any other character you are screwed.
      Generally speaking, it is better to ALLOW characters that you know are safe (whitelisting) than to DISALLOW characters that you know are unsafe.