Is mysql_real_escape_string() Really Safe? The Potential Pitfall with Asian Character Encodings.

Protecting Against SQL Injection: The Limitations of mysql_real_escape_string()

While mysql_real_escape_string() is commonly used to prevent SQL injection, it has been claimed that it can be bypassed with specific Asian character encodings on websites that don't use prepared statements.

The Bypass Issue

According to Justin Shattuck, the bypass is possible by using characters from the Big5 or GBK character encodings. These encodings allow backslashes to be represented as secondary or higher order bytes, which can confuse mysql_real_escape_string() into not escaping them properly.

Stefan Esser's Explanation

Stefan Esser states that the vulnerability arises due to mysql_real_escape_string() not being aware of changes made through SET NAMES, which can switch the encoding. When a multi-byte encoding is used, backslashes can be represented as multiple bytes, potentially bypassing the escape process.

Is UTF-8 Safe?

Esser notes that UTF-8 is an exception to this issue, as it correctly handles backslashes in any byte position. However, he recommends using mysql_set_charset to change encoding, as it's a safer and more recent option.

Recommendations

To fully protect against SQL injection, it's recommended to use prepared statements, which are not susceptible to this bypass issue. If prepared statements are not an option, you should consider the following:

• Avoid using SET NAMES with mysql_real_escape_string()
• Use mysql_set_charset to change encoding when necessary
• Use UTF-8 encoding, as it's not vulnerable to this bypass

The above is the detailed content of Is mysql_real_escape_string() Really Safe? The Potential Pitfall with Asian Character Encodings.. For more information, please follow other related articles on the PHP Chinese website!