freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

安全建设之应用安全
2021-09-29 19:29:40

image-20210928224827503

以上我大概罗列出了在安全建设中所涉及到的几个方面。

漏洞管理

应用安全方面,核心是发现应用系统的安全漏洞。但很多公司,特别是一些刚刚开始投入安全能力的公司往往存在一个问题就是:安全工程师发现了安全漏洞,但业务方并不会及时去修复,甚至会直接无视该漏洞。所以这个时候《漏洞管理流程》是非常必要的,研发部需要按照漏洞管理流程来严格执行。于是安全部屁颠屁颠的出了一个《漏洞管理流程》。但是又遇到一个问题,业务线的有些同学确实按照流程执行了,但仍然有一部同学没有。所以,这个时候管理层就非常重要了,安全leader需要和管理层沟通相关问题,借上层领导之手进行施压才能真正落地安全建设。

image-20210928232505372

有些公司项目多,研发资源紧缺。这种情况下,产品/研发可以和安全同学进行沟通,适当的对漏洞进行降级,排期往后延,但并不是所有的漏洞都可以往后延期。举个例子,我们业务系统分3个等级,核心业务| 核心-边缘业务| 边缘业务。在研发资源紧缺的情况下,核心业务的短信验证码暴力破解漏洞的优先级是紧急,必须一周内完成修复,而核心-边缘业务的水平越权漏洞可以先缓一缓。

安全测试

上面说的是漏洞管理这块,接下来再说一说安全测试。我们现在的安全测试主要分2类,一种是传统漏洞的测试,另一种是业务漏洞的测试。传统漏洞比如SQL注入、XSS、fastjson反序列化我们是交给扫描器来做。扫描器又分主动和被动,主动的我们用awvs和appscan,被动的我们用的xray。当然,传统漏洞也不能完全依赖扫描器,在做安全测试的时候,也会适当的对某些功能进行手工测试和fuzz。

在业务系统中,特别是针对于APP端的web api测试,特别需要关注越权问题。比如越权修改别人的收款账号,消耗别人的积分,查看别人的敏感信息,删除别人账号等。越权查看一般比较容易发现,但是修改、删除的越权操作一般会被忽略,所以这一块需要重点注意。

培训

通过几个月到半年时间的安全测试,基本上已经发现了业务80%的漏洞了。这个时候需要对安全漏洞做一个整理,出现频率TOP 5的重点拎出来给研发侧去培训。通过培训的方式,之前出现过的安全漏洞几乎没有再出现过了。

流程卡点

卡点分为黑盒和白盒,目前我们还没实现黑盒卡点的能力,但已经和devops沟通在做这件事情了。其实很简单,就是发布系统和漏洞管理平台对接。一般我们都是在QA做安全测试,在QA发现了安全漏洞提交到漏洞管理平台,这个时候应用通过ops发布到线上,首先会走卡点流程,判断该应用该版本是否有严重高危漏洞,以及是否中危漏洞超过5个,卡点流程不通过直接会提示发布失败。

白盒卡点我们目前用的是sonarqube,集成了findbug和dependencycheck插件。dependencycheck主要是用来做第三方组件的cve检查。java项目主要是检测pom.XML文件里的依赖库版本,然后通过cpe数据库进行判断该版本是否存在cve。这个插件用处还是挺大的,毕竟现在第三方组件的安全问题还是挺多的,比如fastjson,jackson。具体sonarqube怎么来做gitlab的卡点merge这里就不再过多阐述,大家可以自行百度。

安全评审

这块其实没有过多需要讲的东西,一般情况下就是产品先丢个PRD过来,然后我这边看完prd去再去找产品沟通。有些时候也会在没有任何征兆的情况下被拉到需求评审会议,一般这时候没做任何准备参加评审就会一头雾水。所以,后来能让他们先发文档和PRD的尽量让他们先发我,看过PRD再去参加评审就不会一脸懵逼。评审的时候我一般会提一些设计上的安全问题,比如短信发送接口是否做频次限制?是否做人机验证?再比如上传功能,业务只有上传图片的需求,那是否做文件类型白名单?再比如,提交订单是否做加签验签?

应用安全就先写这么多吧,后面有想到再继续补充。

# 企业安全
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者
文章目录