sql注入笔记一——寻找sql注入点

SQL注入的常见攻击方式和案例分析

让我告诉你SQL注入。
几年前，我在一家电子商务公司工作，见过一次这样的情况。
真是太可怕了。

请记住，那是 2 01 8 年，我们的搜索功能仍然存在问题。
我查看后台发现是SQL注入。
当时有一个朋友在输入框里打字，他输入了“OR'1 '='1 ”之类的东西。
你猜怎么着？我们后端的查询语句不做任何处理，直接把用户输入的材料拼凑起来。
结果，朋友直接帮你查了整个数据库，包括你的订单号、用户名等等一切。
那一刻我们的脸都绿了，于是我们赶紧关掉搜索功能，切换到参数化查询。
我们还降低了数据库用户的权限，限制他们只能搜索，不能删除或修改。
那次事件之后，我们的开发团队每天开会讨论安全问题，代码审查是必须要做的一天。

看看这个东西，不管理论有多深。
如果真的发生了什么事，如果不避免引号的话，一切就都结束了。
我还看到了 Twitter 和雅虎发生的事情。
一个从事研究，另一个从事声乐。
他们都无法控制输入，因此所有数据都被泄露。
Twitter当时至少停止了研究，雅虎泄露了4 5 万用户的数据，后来解雇了所有高管。

如何预防？随后我们总结了几点：
1 ．参数化查询，这东西是真金白银。
正如您所说，使用占位符将 SQL 语句与用户输入分开。
只需在 Python 中使用 sqlite3 .execute(query, (用户名, 密码)) 即可。
我之前的电商网站自从改了之后就从来没有出现过类似的问题。
2 . ORM也非常容易使用。
与Django的ORM一样，如果使用User.objects.filter(username=username)，它可以自己处理转义，节省手动拼接。
不过ORM有时候会有点慢，所以需要注意优化。
3 .授予足够的权限，但不要太多。
只要数据库用户可以控制，就不要给他drop表的权限。
这时我们吸取了教训，专门为 Web 应用程序创建了一个低权限帐户。
4 .WAF是一种帮助，但它不是万能的。
它可以阻止一些明显的攻击，但新的技巧太多，规则需要经常更新。
而且你不能只依赖WAF，你必须自己在代码中编写保护。
5 . 好好过滤你的输入。
不要让用户执行他们输入的操作。
但单独过滤是有风险的，最好对其进行参数化。

归根结底，安全问题不能仅靠几个技术点来解决。
一定要和管理结合起来，比如代码审查、安全培训等等。
这十年我经历过很多陷阱，我知道靠一个人、一个技术点肯定不行。
我们需要让大家团结起来，才能更加稳定。