SQL Injection Bypassing mysql_real_escape_string()
Despite the widespread belief that using mysql_real_escape_string() is sufficient to prevent SQL injections, there do exist scenarios where this defense can be bypassed.
The Attack Vector
One such attack involves a combination of specific conditions:
- Using a vulnerable character encoding (e.g., gbk, cp932)
- Incorrectly setting the connection character set on the client
- Exploiting an edge case where invalid multibyte characters are treated as single bytes for escaping
The Attack Process
- Establish a database connection and set the server's character encoding to a vulnerable one (e.g., 'SET NAMES gbk').
- Construct a payload containing an invalid multibyte character sequence, which will cause it to be misinterpreted as a single byte ('xbfx27 OR 1=1 /*').
- Use mysql_real_escape_string() to "escape" the payload, which will incorrectly insert a backslash before the apostrophe.
- Execute a SQL query using the escaped payload, effectively bypassing the intended protection.
Vulnerable Scenarios
This attack is particularly concerning in the following scenarios:
- Using MySQL versions prior to 4.1.20, 5.0.22, or 5.1.11
- Emulating prepared statements in PDO versions prior to 5.3.6
Mitigation Strategies
To mitigate this vulnerability, it is crucial to:
- Use MySQL versions 5.1 and later
- Properly set the connection character set using mysql_set_charset() or equivalent
- Disable emulated prepared statements in PDO versions prior to 5.3.6
- Consider using non-vulnerable character encodings such as utf8mb4 or utf8
Conclusion
While mysql_real_escape_string() offers essential protection against SQL injections, it is not foolproof. It is crucial to comprehend and address potential bypass mechanisms to ensure the security of your database applications.
The above is the detailed content of Can mysql_real_escape_string() Be Bypassed?. For more information, please follow other related articles on the PHP Chinese website!