views:

34

answers:

1

Note: I've looked at this question: http://stackoverflow.com/questions/1238763/preventing-sql-injection-without-prepared-statements-jdbc . And as I somewhat expected... the answer is to use prepared statements. I'm in a different set of circumstances... so I'd like to know the best path for this.

I'm using a downloaded script (phpsimplechat) where the author wrote his own simple SQL layer (notice: it supports PostgreSQL and MySQL). Unfortunately, I've ran some tests on it and it is vulnerable to SQL Injection. The script does everything I want simply from a features standpoint, so I'd like to salvage it.

Fortunately, it is open source... but I'd rather not rewrite all of the SQL queries to use prepared statements in phpsimplechat. The 3rd party library uses its own SQL layer instead of PDO... and under that uses the older mysql module (thus, I can't use prepared statements. Even if I changed mysql -> mysqli, I have to deal with "dbQuery" layer he put on top of all of his code). I do NOT need the PostgreSQL code, so answers can be MySQL specific.

I've read that addslashes is insufficient to protect against all SQL Injection attempts. Is mysql_real_escape_string safe to use?

+2  A: 

Yes, mysql_real_escape_string is guaranteed to be safe if you use it correctly, i.e. make sure that all strings appearing in queries are escaped.

casablanca