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 --
[download]

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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.