这是一个创建于 3098 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 昨天晚上已经 11 点多的时间，一个朋友突然找我说她们公司的网站的漏洞被提交到 wooyun 了。（然后就跟妹子大概了解了一下漏洞的情况 PS ：妹子是 php 程序员）
- 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 语句的函数,分享一下,谢谢!
 |
1
ryd994 2016-06-11 10:05:04 +08:00 via Android
公司不会让她改，那叫什么让她修？
|
 |
2
wujunze OP PHP 系统函数有这个 addslashes() 不知道好不好使?
|
 |
4
Sunyanzi 2016-06-11 10:30:53 +08:00  2
最原始的安全处理办法叫 mysql_real_escape_string ... 虽然也不是 100% 安全但至少比 addslashes 好多了 ...
要 100% 安全的话 ... 如果不能用原生的 Prepared Statement 的话 ... 只能在查询执行之前验证所有传入值了 ... 另外还有一种笨办法 ... 写几十甚至上百个 str_replace / preg_replace ... 把所有乱七八糟的东西都替换掉 ... |
 |
5
xiandao7997 2016-06-11 10:39:15 +08:00 via Android
妹子一定很好看，所以 lz 才这么愿意帮忙
|
|
6
wujunze OP @Sunyanzi 其实写几个 str_replace()就差不多 OK 了 mysql_real_escape_string()这个函数可以试试 谢谢你的建议
@xiandao7997 你太聪明了 23333 |
 |
7
huigeer 2016-06-11 11:32:14 +08:00 via iPhone
找个第三方的云服务，自带 waf,预防各种 sql 和 xss
|
 |
8
mchl 2016-06-11 11:52:44 +08:00 via Android
statement
|
 |
9
tSQghkfhTtQt9mtd 2016-06-11 12:12:46 +08:00 via Android
|
 |
10
initialdp 2016-06-11 12:22:55 +08:00
先用正则表达式过滤，最终还是应当换 pdo ，花费一点时间，可以解决后续无穷无尽的烦恼。
|
 |
11
fcicq 2016-06-11 12:25:33 +08:00
SQL 注入都搞不定就别考虑安全的事情了, 这里补上了别处还有, 多补一个少补一个不影响糟糕的安全状况.
|
 |
12
Kirscheis 2016-06-11 12:58:33 +08:00 via Android
有一种东西叫做 WAF 。
除非经验很多否则不要自己尝试过滤注入，光 sqlmap 的 tempers 就够你喝一壶的，还不算各种私有积累的奇技淫巧。 看这妹子的水平防入侵基本上没什么希望了，公司没有安全工程师的话还是老老实实装个 WAF 吧 |
|
13
wujunze OP |
 |
14
XianZaiZhuCe 2016-06-11 15:04:56 +08:00 via iPhone
对所有输入参数进行强验证。副文本内容设置白名单。
PDO 我都不考虑这些。个别情况就用强验证。 |
|
15
fcicq 2016-06-11 15:10:02 +08:00 1
@wujunze SQL 只是一个侧面. 不补 SQL 基本也可以证明补丁也不会及时打上等等, 这种安全意识下有或者没有表象的漏洞已经无关紧要了, 而不是去求一个洞直接去打穿, 更倾向于出现下一个普遍性漏洞的时候没有能力及时处理从而受害.
|
 |
17
mengzhuo 2016-06-11 21:45:32 +08:00 via iPhone
都 2016 年了竟然还有自己拼 sql 的……
uid 那个属于没有安全意识 |
|
19
mengzhuo 2016-06-11 23:36:34 +08:00
|
 |
20
hylent 2016-06-12 00:09:27 +08:00 via Android
并不是替换 pdo 就可以防止 sql 注入 而是使用 pdo 的姿势过滤用户输入啊…
手拼 sql 直接 query 换啥也不好使啊… waf 或者匹配关键词的办法容易误判 治标不治本啊 不过推荐给妹子 够了 |
 |
21
Felldeadbird 2016-06-12 09:42:45 +08:00
上个安全狗，可以抵御大部分的注入了。
所有 SQL 的外部参数记得用 引号包含着。 然后结合 addslashes 使用。 基本可以安全了。只是这样做，可能会导致某些奇葩的数据 取出来时异常。 |
|
22
wujunze OP |
|
23
Felldeadbird 2016-06-12 10:29:29 +08:00
@wujunze 我刚才说的就是了。
|
 |
24
Lcys 2016-06-12 10:50:44 +08:00
怕死 用 360webscan.php
|
 |
25
RIcter 2016-06-15 08:28:03 +08:00
全面改用 PDO 吧，其他的 WAF 多多少少能绕过的。
目前一个难以绕过的 WAF 是 Discuz 的内置 WAF 。 |
Select Language