Android APP漏洞之战——SQL注入漏洞初探

报错注入原理分析

当天调试程序时，用户提交了一个特别长的参数，结果页面出现“MySQL服务器已消失”的错误。
检查日志后发现查询语句因为参数太长而直接阻塞了数据库连接。
嘿，这不是典型的数据类型溢出吗？当时系统还在使用MySQL 5 .6 版本。
如果我迁移到旧版本，我可能会直接报告“重复列名”错误。

等等，还有一件事。
当我测试旧系统时，我发现它实际上直接在错误页面上返回了mysql_error()函数的返回值。
当用户输入“AND 1 =(SELECT COUNT() FROM information_schema.tables) -
”时，错误消息中会打印整个数据库表列表。
那是 2 01 9 年 3 月，服务器还是物理机，插在办公室角落的插座上，IP 地址还是 1 9 2 .1 6 8 .1 .1 00...
我突然想到，现在很多系统都使用了更友好的错误处理机制，比如统一返回“系统遇到小问题，请稍后再试”的消息。
但有时用户仍然可以从响应时间或 HTTP 标头中发现线索。
比如，有一次，我故意构造了一次XPATH错误注入，发现响应时间比正常请求慢了足足3 秒：这个延迟，在用户眼里，和“系统有点卡”没有什么区别……
防御方法中提到的数据库防火墙是我们团队去年刚实现的，但最近有同事发来工单说拦截了一个用JOIN的正常查询。
当时系统日志显示“SQL疑似危险，被阻塞”，但实际上只是忘记添加索引了。
这件事让我不禁思考：安全措施应该有多“暴力”？你宁愿错杀1 000人，还是放走一个人？

什么是sql注入攻击