前一段时间安全部门测出某个程序存在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，虞大胆的叽叽喳喳）
