注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

phperwuhan的博客

记载一个phper的历程!phperwuhan.blog.163.com

 
 
 

日志

 
 

[重要]addslashes() Versus mysql_real_escape_string()  

2013-06-24 08:19:40|  分类: php |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
来源:http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Last month, I discussed Google's XSS Vulnerability and provided an example that demonstrates it. I was hoping to highlight why character encoding consistency is important, but apparently the addslashes() versus mysql_real_escape_string() debate continues. Demonstrating Google's XSS vulnerability is pretty easy. Demonstrating an SQL injection attack that is immune to addslashes() is a bit more involved, but still pretty straightforward.

In GBK, 0xbf27 is not a valid multi-byte character, but 0xbf5c is. Interpreted as single-byte characters, 0xbf27 is 0xbf (?) followed by 0x27 ('), and 0xbf5c is 0xbf (?) followed by 0x5c (\).

How does this help? If I want to attempt an SQL injection attack against a MySQL database, having single quotes escaped with a backslash is a bummer. If you're using addslashes(), however, I'm in luck. All I need to do is inject something like 0xbf27, and addslashes() modifies this to become 0xbf5c27, a valid multi-byte character followed by a single quote. In other words, I can successfully inject a single quote despite your escaping. That's because 0xbf5c is interpreted as a single character, not two. Oops, there goes the backslash.

I'm going to use MySQL 5.0 and PHP's mysqli extension for this demonstration. If you want to try this yourself, make sure you're using GBK. I just changed /etc/my.cnf, but that's because I'm testing locally:

Toggle Code View

  1. [client]
  2. default-character-set=GBK

Create a table called users:

Toggle Code View

  1. CREATE TABLE users (
  2. username VARCHAR(32) CHARACTER SET GBK,
  3. password VARCHAR(32) CHARACTER SET GBK,
  4. PRIMARY KEY (username)
  5. );

The following script mimics a situation where only addslashes() (or magic_quotes_gpc) is used to escape the data being used in a query:

Toggle Code View

  1. <?php
  2.  
  3. $mysql = array();
  4.  
  5. $db = mysqli_init();
  6. $db->real_connect('localhost', 'myuser', 'mypass', 'mydb');
  7.  
  8. /* SQL Injection Example */
  9. $_POST['username'] = chr(0xbf) .
  10. chr(0x27) .
  11. ' OR username = username /*';
  12. $_POST['password'] = 'guess';
  13.  
  14. $mysql['username'] = addslashes($_POST['username']);
  15. $mysql['password'] = addslashes($_POST['password']);
  16.  
  17. $sql = "SELECT *
  18. FROM users
  19. WHERE username = '{$mysql['username']}'
  20. AND password = '{$mysql['password']}'";
  21.  
  22. $result = $db->query($sql);
  23.  
  24. if ($result->num_rows) {
  25. /* Success */
  26. } else {
  27. /* Failure */
  28. }
  29.  
  30. ?>

Despite the use of addslashes(), I'm able to log in successfully without knowing a valid username or password. I can simply exploit the SQL injection vulnerability.

To avoid this type of vulnerability, use mysql_real_escape_string(), prepared statements, or any of the major database abstraction libraries.

This type of attack is possible with any character encoding where there is a valid multi-byte character that ends in 0x5c, because addslashes() can be tricked into creating a valid multi-byte character instead of escaping the single quote that follows. UTF-8 does not fit this description.

  评论这张
 
阅读(404)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017