PHP versions prior to 6 have a basic guard against injection attacks that attempts to escape "dangerous characters". This guard is called "magic quotes". It's an optional setting, so your hosting provider may have it turned off. Starting with version 6, this protection is removed, as it's caused a lot of problems for coders. So you should be rethinking your input validation to ensure compatibility and security when you upgrade your PHP platform.

http://www.tizag.com/phpT/php-magic-quotes.php

Here's how SQL injection attacks work:

http://www.unixwiz.net/techtips/sql-injection.html

Most if not all queries are escaped in the wowdb layer. This helps TONS against sql injection.

Plus Roster code (since 1.7.1) detects magic quotes and escapes all global strings if it is off

am i right that as long as you escape all single and/or double quotes, then injection is impossible?

Not impossible, but it reduces it by a s#it tonne, lol

Queries in search.php didn't seem to be escaped, but I didn't follow them down into the wowdb layer. That's what prompted me to post this.

In 1.7.2, I don't see where wowdb::query() invokes escape(). Bug in search.php or wowdb.php, or am I just missing the right piece of code?

Matt, best practices in untrusted input are to specify what you accept, not what you exclude. Escaping is really the latter. When you do that, it's much harder to prove that you're safe. But it at least cuts your exposure.

All GET, POST, COOKIE data gets escaped in settings.php (Since 1.7.1, I think). The rest of roster has been modified to assume those variables are already escaped.

The current philosophy for R2 uses queries with parameter binding everywhere. This doesn't mean the base queries are completely given as string literals, but only the table names would be added in. The query parameters (mainly WHERE conditions) that are currently the ones we've got to watch out to escape properly, are passed to MySQLi separately, so there is no risk of SQL insertion there.