sql注入比我想象的更危险

前一段时间安全部门测出某个程序存在sql注入漏洞，在我原来潜意识中一直认为构造危险的 sql 语句是相对较难的，所以没有绷紧神经，总认为就算存在漏洞，也很难被实际攻击，总抱有侥幸心理，但这次事件却给了我很大一个教训。

sql 注入如何产生的

某个程序对 URL id 参数没有做严格的限制，正常的情况下，会这样执行：

update table set id = {id} where name = 'login'

如果攻击者传递 id 参数是 1 and sleep(5) --，则会构成一条危险的 SQL 语句：

update table set id = 1 and sleep(5) -- where name = 'login'

开始我倒没太在意（只能说太不敏感了），虽然注入了，但仅仅对我们不重要的一个表进行了全表替换。第二个伤害我认为是 sql 执行 延迟了 5 秒而已。

后来发生的事情（下面会说）才让我猜测到这条语句耗时很久，假设 table 表有 10 条记录，那么整个 sql 语句会执行 50 秒，全表锁定了 table 表的 update 操作。

当然这个sleep 耗时如此之长是我后面发现的，怎么发现的呢？看下面。

全表锁定

注入发生的第二天，同事说某个功能总是不成功，页面总是超时，我排查了下，发现该功能执行的一个关键 sql （在同一个库）居然超时报错了：

update table2 set tb =2 where id=3

我在 mysql 终端执行了下 show full processlist

87 | db | ip:port | Query   | 93724 | User sleep | update table set id = 1 and sleep(5) -- where name = 'login' |

居然发现 sql 注入语句还在执行，而其他的 update 操作由于 table 表被全表锁定了，一直在等待，积累了很多的 update 操作。

同时执行 show global status：

| Innodb_row_lock_current_waits   | 77 |

确实显示 77 个操作被锁了。

立刻反馈给了 DBA 同时，他们执行了 information_schema 库的相关操作：

SELECT r.trx_id waiting_trx_id,r.trx_mysql_thread_id waiting_thread,r.trx_query waiting_query,b.trx_id blocking_trx_id,b.trx_mysql_thread_id blocking_thread,b.trx_query blocking_query FROM innodb_lock_waits w INNER JOIN  innodb_trx b ON b.trx_id = w.blocking_trx_id INNER JOIN innodb_trx r ON r.trx_id = w.requesting_trx_id ;

也显示被锁定了，立刻在 mysqld 端 kill 了这条语句，服务正常运行了。

这个时候我才意识到 sql 注入的危害比我想象的大多了。

沉思

对于我们开发者来说，知道 sql 注入是危险的，但如何构造危险 sql 可能是很难的，可怕的是现在居然有这样的工具（比如 sqlmap），那么危险的 sql 会产生什么后果：

• 偷窥：导出全表数据

• 破坏：更新、删除记录

sqlmap

sqlmap 是一个渗透测试工具：

sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.

我完全不会使用该工具，总感觉什么白帽子、红帽子、黑帽子都不是啥好东西...，他们带来好处的同时也带来极大的危害。

同事使用了下这个工具，我在旁边看了一会，感觉功能太强大了，虽然不知道它的实现原理，但很想搞明白，经过同事的测试，发现几个原理：

• 要完整注入，被注入程序必须要打印结果，否则很多 sqlmap 功能（比如导出表结构）会失效。

• information_schema 被极大的利用了，没有特殊需求，要关闭它的操作权限。

• sqlmap 有 session data，比如它将整个库表结构 dump 到 session data。

上面几个原理都是我通过观察 mysql 日志发现的，要开启 mysql 日志，打开 my.cnf :

general_log_file  = /var/log/mysql/mysql.log

然后一边运行 sqlmap，一边观察 general_log_file 日志。

接下去讲解 sqlmap 的几个操作：

sqlmap.py -u "http://localhost/test/db.php?id=1" --batch --schema 
sqlmap.py -u "http://localhost/test/db.php?id=1" --batch --tables

其中让我惊叹它功能强大的是能执行 shell：

sqlmap.py -u "http://localhost/test/db.php?id=1" --batch --sql-shell

实现 shell 原理其实也不复杂，就是它内部又调用了下 db.php，然后将结果输出，本质上并没有啥区别。

本文发表于【2018-12-20】，地址是https://mp.weixin.qq.com/s/89t2vW--z4ElaKklQwYuCQ，欢迎大家关注，我的公众号（ID：yudadanwx，虞大胆的叽叽喳喳）

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=Naeb1972f-a763-434b-9054-4700152adeb5