Is `mysql_real_escape_string()` a Reliable Defense Against SQL Injection in All Character Encodings?

Is mysql_real_escape_string() an Impregnable Shield Against SQL Injection?

A section on justinshattuck.com suggests that mysql_real_escape_string() is fallible against certain Asian character encodings. Specifically, it claims that the encoding bypasses mysql_real_escape_string() using BIG5 or GBK to smuggle dangerous characters into queries.

Is This Vulnerability Real?

According to Stefan Esser, the answer is a disconcerting yes. He claims that mysql_real_escape_string() falters when SET NAMES is employed. This method switches encoding to suit the application's needs without informing mysql_real_escape_string(). Consequently, if a multi-byte encoding allows backslash as the second, third, or fourth byte, trouble ensues. Mysql_real_escape_string() remains oblivious to this irregularity and fails to escape the characters correctly.

Protecting Your Website

Esser suggests that UTF-8 remains a safe encoding, but UTF-8 is not always an option. Unfortunately, mysql_set_charset, the safer alternative, is only available in recent PHP versions.

The above is the detailed content of Is `mysql_real_escape_string()` a Reliable Defense Against SQL Injection in All Character Encodings?. For more information, please follow other related articles on the PHP Chinese website!