专注于Java领域优质技术号，欢迎关注

前一段时间安全部门测出某个程序存在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 "" --batch --schema sqlmap.py -u "" --batch --tables

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

sqlmap.py -u "" --batch --sql-shell

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

来自：