MySQL Injection Vulnerabilities with mysql_real_escape_string()
Despite its widespread use, mysql_real_escape_string() may not fully protect against SQL injection attacks under specific circumstances.
Asian Character Encodings
According toJustinShattuck.com, certain Asian character encodings can bypass mysql_real_escape_string(), as demonstrated by the example using Chinese Big5 characters. This vulnerability arises when:
- mysql_real_escape_string() is used.
- SET NAMES is used to switch the default character encoding to a multibyte encoding.
- The chosen multibyte encoding allows backslashes ("") as second, third, or subsequent bytes.
Impact and Mitigation
As Stefan Esser explains, this vulnerability occurs because mysql_real_escape_string() does not account for the encoding changes caused by SET NAMES. To address this issue:
-
Prefer prepared statements: Prepared statements handle character encoding correctly and are generally more secure.
-
Use mysql_set_charset (if available): This newer function allows safe encoding changes without the vulnerability present in mysql_real_escape_string().
-
Limit character encoding options: Restrict the character encodings that can be used by your application to prevent vulnerabilities.
-
Be cautious with UTF-8: While UTF-8 is generally safe, malicious users may attempt to exploit edge cases and should be monitored.
The above is the detailed content of Here are a few title options, keeping in mind the question-and-answer format and highlighting the core issue:
Option 1 (Direct and Specific):
* Can mysql_real_escape_string() Protect Against SQL Inj. For more information, please follow other related articles on the PHP Chinese website!