降低SQL注入带来的危害

参考 记一次标准化SQL注入 的流程,再次注入了 某网站, 同时也证明程序的漏洞确实无处不在,所以作为用户千万别把什么都搁网上.作为开发者必须对自己的代码更加负责,尽可能减少被攻击的可能性以及受到攻击后将可能的危害设在一个可控的范围内,否则,很可能造成非常严重的损失.

大部分程序员对自己写的代码非常有信心,认为自己编写的代码是非常严谨的而对其他方面的安全性问题放松了警惕,这往往是最危险的做法.其实,如果稍微做一点工作,即使出现漏洞,大部分攻击也很难对程序(或网站)造成实质性的破坏,以下是目前想到的一些简单的防范措施,经供参考:

  • 对不同的项目配置独立的数据库权限,避免因为某一个网站的漏洞而造成大面积的跨库攻击.同时,也不要给项目数据库用户提供mysql, infomation_schema 等系统级数据库的权限,避免攻击者很容易就得到数据库的结构信息.

  • 数据表的命名不要过于常规,如 user 等,实在是太容易被猜到了.

  • 关闭各种报错信息,可以有效提高攻击的难度,如果不是有目的的攻击者,遇到只能盲注的一般也就放弃了.

  • 到现在还有大量的开发者认为MD5是安全的加密方式, google一下,做各种 Hash型密码破解 的网站真的是越来越牛逼,8位以下的数字密码不用付费都给你了, 作为被攻击并被爆表后,网站的最后一道防线,请重视一点,至少不要使用太常规的加密方式,不然真的没办法了.

  • 开发完成后,最好用APPScan之类的检测工具自己扫描一下,应该能发现不少问题.

  • 最后一点,千万不要觉得二次开发的产品就很安全,写开源软件的不都是大神,开源软件也很可能是我这样的代码猴子写出来的,所以,请还是亲力亲为地自己检查一下.

  • 如果以上各点枪枪全中(其实不用全中,有个2,3个就足够了),那基本上是死定了,即使是现在没有BUG,也难保在各种压力下迭代的过程不会出现BUG. 下场嘛,就和 CSDN ,或者 2000w 什么的差不多.

对于这种完全无视安全的网站,再恰逢解码网站测试,全部数据统统免费,只好写一个小爬虫,把用户数据全部爬出来再解个密.想到以前为了帮别人搞一个学校就业账号到处问人,现在不光有了2w个账号我还能发就业信息,还是值了.

Show Comments