sql注入比我想象的更危险 | 码农网_ZGC一个超乎想象的垃圾收集器码农网

时间:2021年10月17日 10:40:16

前一段时间安全部门测出某个程序存在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 table2set 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 JOINinnodb_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--schemasqlmap.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://blog.51cto.com/nav/software1