字符集SQL注入

最新推荐文章于 2022-09-13 22:58:40 发布

转载最新推荐文章于 2022-09-13 22:58:40 发布 · 995 阅读

文章标签：

#mysql

SQL 专栏收录该内容

4 篇文章

订阅专栏

本文详细介绍了如何通过特定字符集设置绕过PHP中的mysql_real_escape_string函数进行SQL注入攻击的方法，并给出了具体的PHP代码示例。此外，还提供了有效的防范措施。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

SQL注入

以前只是知道部分字符集转化时会导致注入，并未找到实际例子，现在看到了记录一下。

BIG5, CP932, GB2312, GBK and SJIS are blacklisted as they may introduce a SQL injection vulnerability!

代码(php语言)

mysql_query('SET NAMES gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

原理
- Selecting a Character Set
```
mysql_query('SET NAMES gbk');
```
  For this attack to work, we need the encoding that the server's expecting on the connection both to encode' as in ASCII i.e. 0x27 and to have some character whose final byte is an ASCII \ i.e. 0x5c. As it turns out, there are 5 such encodings supported in MySQL 5.6 by default: big5, cp932, gb2312, gbk and sjis. We'll select gbk here.
  
  Now, it's very important to note the use of SET NAMES here. This sets the character set ON THE SERVER. If we used the call to the C API functionmysql_set_charset(), we'd be fine (on MySQL releases since 2006). But more on why in a minute...
- The Payload
  
  The payload we're going to use for this injection starts with the byte sequence 0xbf27. In gbk, that's an invalid multibyte character; in latin1, it's the string ¿'. Note that in latin1 and gbk, 0x27 on its own is a literal ' character.
  
  We have chosen this payload because, if we called addslashes() on it, we'd insert an ASCII \ i.e. 0x5c, before the ' character. So we'd wind up with 0xbf5c27, which in gbk is a two character sequence: 0xbf5c followed by 0x27. Or in other words, a valid character followed by an unescaped '. But we're not using addslashes(). So on to the next step...
- mysqlrealescape_string()
  
  The C API call to mysql_real_escape_string() differs from addslashes() in that it knows the connection character set. So it can perform the escaping properly for the character set that the server is expecting. However, up to this point, the client thinks that we're still using latin1 for the connection, because we never told it otherwise. We did tell the server we're using gbk, but the client still thinks it's latin1.问题就出在latin1转成gbk过程中。
  
  Therefore the call to mysql_real_escape_string() inserts the backslash, and we have a free hanging ' character in our "escaped" content! In fact, if we were to look at $var in the gbk character set, we'd see:
```
縗' OR 1=1 /*
```
- The Query
  
  This part is just a formality, but here's the rendered query:
```
SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1
```

防范

If you:

Use Modern Versions of MySQL (late 5.1, all 5.5, 5.6, etc) AND mysql_set_charset() / $mysqli->set_charset() / PDO's DSN charset parameter (in PHP ≥ 5.3.6)

Don't use a vulnerable character set for connection encoding (you only use utf8 / latin1 / ascii / etc)

You're 100% safe.

原文

http://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string/12118602#12118602

http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string