大家一起研究一下 SQL 注入的防范姿势

[wujunze]

1. 昨天晚上已经 11 点多的时间，一个朋友突然找我说她们公司的网站的漏洞被提交到 wooyun 了。（然后就跟妹子大概了解了一下漏洞的情况 PS ：妹子是 php 程序员）
2. wooyun 上提交了两处漏洞,1 处是 SQL 注入 (经过了解,她们公司的用的框架是 11 年的老框架,还是mysql_query()这些老的 mysql 函数) 另一处就是 cookie 的问题,妹子把用户的 uid,等敏感信息都写进 cookie 了,2333 。然后 php 处理业务逻辑的 uid 也是从 cookie 里面拿的,233333 (导致修改 cookie 后可以伪装成任意用户)
   3.我给她说了 SQL 注入的解决方案(第一种治标不治本的,用正则匹配 SQL 语句,过滤危险字符,关键字,转义符号,第二种方案,弃用 mysql 老函数,用 PDO 或者 mysqli)(cookie 那个地方的漏洞,我建议她把 uid 等敏感信息存在 session 里面,然后把 sessionID 加密后放在 cookie 里面)
   4.妹子最后说,她大概听懂了.改公司框架的 mysql 驱动是不太现实的,公司不会让她改的,那就只好用正则匹配 SQL 语句,过滤非法字符串了!
   5.我就去网上找了一些 SQL 语句过滤的函数 号称很好用的 SQL 过滤函数 知乎大婶们的回答

想跟 V 友们讨论一下 SQL 注入防范的姿势 大家有没有比较好用的 SQL 注入 过滤 SQL 语句的函数,分享一下,谢谢!

[ryd994]

公司不会让她改，那叫什么让她修？

[wujunze]

PHP 系统函数有这个 addslashes() 不知道好不好使?

[wujunze]

@ryd994 可以改 SQL 语句过滤 不会让她把 mysql 老函数换成 PDO 的 你好像答跑题了 23333

[Sunyanzi]

最原始的安全处理办法叫 mysql_real_escape_string ... 虽然也不是 100% 安全但至少比 addslashes 好多了 ...

要 100% 安全的话 ... 如果不能用原生的 Prepared Statement 的话 ... 只能在查询执行之前验证所有传入值了 ...

另外还有一种笨办法 ... 写几十甚至上百个 str_replace / preg_replace ... 把所有乱七八糟的东西都替换掉 ...

[xiandao7997]

妹子一定很好看，所以 lz 才这么愿意帮忙

[wujunze]

@Sunyanzi 其实写几个 str_replace()就差不多 OK 了 mysql_real_escape_string()这个函数可以试试 谢谢你的建议
@xiandao7997 你太聪明了 23333

[huigeer]

找个第三方的云服务，自带 waf,预防各种 sql 和 xss

[mchl]

statement

[tSQghkfhTtQt9mtd]

https://lwl.moe/VLBgD
仅供参考，无责任安利（
（不是我写的

[initialdp]

先用正则表达式过滤，最终还是应当换 pdo ，花费一点时间，可以解决后续无穷无尽的烦恼。

[fcicq]

SQL 注入都搞不定就别考虑安全的事情了, 这里补上了别处还有, 多补一个少补一个不影响糟糕的安全状况.

[Kirscheis]

有一种东西叫做 WAF 。
除非经验很多否则不要自己尝试过滤注入，光 sqlmap 的 tempers 就够你喝一壶的，还不算各种私有积累的奇技淫巧。
看这妹子的水平防入侵基本上没什么希望了，公司没有安全工程师的话还是老老实实装个 WAF 吧

[wujunze]

@fcicq 呵呵哒 SQL 你来搞定啊
@huigeer 用过 WAF 也可以
@initialdp PDO 确实是个好办法 老项目的迁移 需要很大工作量 他们公司不愿意迁移
@Kirscheis 妹子的安全意识确实比较低 让她装个 WFA

[XianZaiZhuCe]

对所有输入参数进行强验证。副文本内容设置白名单。
PDO 我都不考虑这些。个别情况就用强验证。

[fcicq]

@wujunze SQL 只是一个侧面. 不补 SQL 基本也可以证明补丁也不会及时打上等等, 这种安全意识下有或者没有表象的漏洞已经无关紧要了, 而不是去求一个洞直接去打穿, 更倾向于出现下一个普遍性漏洞的时候没有能力及时处理从而受害.

[wujunze]

@fcicq 大神 你说的有道理 23333

[mengzhuo]

都 2016 年了竟然还有自己拼 sql 的……
uid 那个属于没有安全意识

[wujunze]

@mengzhuo 看来你没有实际工作吧? 有的老公司 老框架 自己拼 SQL 很正常

[mengzhuo]

@wujunze
不好意思呢，我 2012 年才参加工作，第一个做的就是 DB2 转 MySQL 。
老公司也会用新技术的，架构偷懒不进化，代码不审查、安全意识薄弱，可以说是工作不负责任。

[hylent]

并不是替换 pdo 就可以防止 sql 注入 而是使用 pdo 的姿势过滤用户输入啊…
手拼 sql 直接 query 换啥也不好使啊…
waf 或者匹配关键词的办法容易误判 治标不治本啊 不过推荐给妹子 够了

[Felldeadbird]

上个安全狗，可以抵御大部分的注入了。
所有 SQL 的外部参数记得用 引号包含着。 然后结合 addslashes 使用。 基本可以安全了。只是这样做，可能会导致某些奇葩的数据 取出来时异常。

[wujunze]

@hylent
@Felldeadbird 先给妹子推荐过滤 SQL 语句吧 指标不本的解决方法

[Felldeadbird]

@wujunze 我刚才说的就是了。

[Lcys]

怕死 用 360webscan.php

[RIcter]

全面改用 PDO 吧，其他的 WAF 多多少少能绕过的。
目前一个难以绕过的 WAF 是 Discuz 的内置 WAF 。