本文是白帽子谈web安全的思考
通常情况下这些年出的新的架构都会大幅度优化安全的风险,使用官方文档中带的那些的标准方法就能很有效避免错误.php官方在5.5之后给了password_hash方法,直接使用就可以存储代码,再比如我常用的ci框架下,就建议使用链式查询模型,这样就可以有效避免sql注入(当然还是有bug的,比如使用key-value数组下就存在漏洞).
通常使用文档下的新方法和新框架往往能避免漏洞,老的legal code就一般更新慢,就有问题,前一段时间闹得沸沸扬扬的Log4j漏洞,就是如此,在老版本java版本下这个漏洞暴露无遗,作为基础代码库的一部分,这个广泛使用的代码却没有被审视.使用高版本的jdk就可以有效解决这个问题,但是某些公司因为种种原因不愿意更新jdk,反倒是让这些问题遗祸至今.
总之系统里面的老代码尤其要小心,如果是用老版本的代码,能升级尽量升级,不能升级就要花更多精力去考察安全问题,渗透测试与漏洞多使用工具去考察
通常情况下我遇到的情况都是不愿意升级架构,宁可用老式的架构,理由一般都是担心哪里出现问题,实际上更多的原因我认为是害怕出现问题,升级的主管要负责,这个责任很难背上,而升级往往缺少显性的好处.责任与优点不对等,很难说服产品经理和技术主管升级.我上文提到了的Log4j漏洞,当时给的一个解决方案就是升级就可以解决,实际上由于这个问题,很多公司之前停滞了很久的升级问题都解决了
实际上如果是架构合理,有完整的测试环境,自动化测试工具,只是架构升级实际上是非常快捷的事情,当然这也是技术主管需要考虑的问题,在一开始选择合适的技术栈,docker,部署工具和自动化测试工具,文档,一个好的舒适的技术环境,反而容易推动升级.
我之前在一家公司上班的时候,一直使用老版本的php,不愿意升级,理由嘛总是没时间,没空,容易出问题,然后当我离职前,就升级到了7,最后所谓的容易出问题并没有发生.
实际上,通常情况下按照标准的流程走下去都不容易产生漏洞和问题,但是一旦偏离流程就容易捅娄子,一般一个需求,才能够讨论需求,到技术讨论实现,到开发,测试,安全扫描,部署,一系列流程走下来确实会时间,但是通常情况下问题也会被发现和解决.反而是紧急需求,临时上限,不走流程,往往会捅出篓子,我认为应该有的解决方法,
- 紧急需求
- 紧急讨论
- 开发
- 测试并上线
这时候不应该结束,应该在补充之前缺失的环节,比如在研究和讨论之前的上线的逻辑是否有漏洞,是否需要补充说明文档,自动化测试的代码可以再新版本补全.就算是新版本上线了,也不应该忽视他.
一个字,抄,我个人认为参考别家的产品的逻辑是非常有用的,比如在我没看<白帽子谈web安全> 最后一章节运营安全之前,我是不知道登陆会有这么多门门道道,只是有一个粗浅的猜测,
比如可以在登录的应用中检测暴力破解的尝试。检查一个账户在一段时间内的登录失败次数，或者检测某一个IP地址在一段时间内的登录行为次数。这些行为都是比较明显的暴力破解特征。暴力破解往往还借助了脚本或者扫描器，那么在检测到此类行为后，向特定客户端返回一个验证码，也可以有效地缓解暴力破解攻击。
实际上看完之后,我发现我们之前开发的登陆逻辑因为抄的某大厂和某竞品,也就没有大的安全问题.当然还有不完善的地方,比如登陆日志系统和检测系统,这个确实是有必要补全.
总之,重要的核心流程,抄是没有问题的,别人大厂和公用产品往往久经考验和设计一般不会有大的疏漏,当然在抄的时候也要考虑到别人为什么这样设计,只有这样才能提高自己
- 经常使用的sql注入漏洞,尤其是自己拼接类型的sql代码,这个是注入的极有可能出现问题的地方.
- 避免使用常用端口这个事情非常容易搞事和攻击的地方
- 端口开放问题,这个不用说了,阿里云现在很方便开发了
- 文件上传,之前有过直接上传到本地服务器的丑事,不过那是年轻不懂事弄着玩.还没有开发的概念,现在想来肯定不能这么干,隐患太大了.首先是现在通用的oss服务器上传图片,其次就就算是文件处理的需求也要放到使用临时目录,最好限制是文件和上传用户的权限
- 远程调用命令,这个算是大坑了,之前开发的某个模块要使用linux的命令,现在想起来真的是超级危险,感觉当时就应该考虑用好好开会讨论换一套解决方案,或者用其他的流程处理
- 错误暴露,这个之前遇到过,不过也是在测试环境暴露,实际上正式环境一般不会允许暴露错误代码,要在nginx那一层拦截掉错误显示