从零开始内建你的安全测试流程
本帖最后由 草帽路飞UU 于 2022-8-12 14:54 编辑一、 安全测试的意义
安全问题，没发生的时候我们可以侥幸，一旦发生生产安全问题，对很多公司来说可能就是黑天鹅事件了。平台的安全，是我们测试中不可舍弃的一环，而且需要长期持续的关注。
二、 从哪里入手
很多公司没有专职的安全测试人员，一个是安全涉及的技术栈比较广，要做好还需要对每一个技术栈有深入的研究，市面上的安全人才是很稀缺的；另外一般小公司去养一个专职的安全人员，往往会去对比第三方安全外包平台，发现提交外包平台会更划算。
团队中没有安全人员，特别是在敏捷的当下，也不可能每一次迭代都提交第三方外包，那作为测试人员，我们就需要去思考，如何在测试流程中插入安全测试这一环，毕竟生产出损，你是无法置身事外的，引入安全测试也能为公司带来价值。
那么我们该如何开展安全测试呢，很多同学目前可能直接用APPscan或zap进行扫描，这也是一个方式，但有些业务相关的安全问题这种工具是无法识别到的，有些还是需要手工环节的接入，安全测试也是测试的一种类型，在整个软件研发的生命周期中，我们是如何去保障产品质量的？同样，我们也按照这个思路，去建设我们的安全测试执行路径。
三、 万丈高楼从地起，打造我们的安全测试流程
3.1 需求阶段
在需求评审阶段，我们除了关注需求的合理性和价值，还要加入破坏者思维去审视这个需求–这个需求哪里有漏洞，可以让我去破坏他的规则。
比如商家做活动，评论下点赞越多的发送礼品，那么我是不是可以通过接口去不断的刷点赞，让你接口tps过载，导致别人无法点赞，这样我就有更大的机会拿取礼品。所以这样就引申出来一个安全性需求–我们需要对活动的点赞和评论做限流处理。
3.2 代码层面
·静态代码扫描
我们可以引入静态代码扫描工具，比如静态代码扫描，目前也有很多开源的静态代码扫描工具，比如大家常用的sonar。
·三方组件的扫描
除了静态代码的扫描，开发人员在引用第三方依赖包的时候，获取来源比较随意，很可能下载的这个依赖包就包含病毒，程序中集成的第三方的组件也是需要做安全扫描的，比如node的依赖包安全扫描就可以选择nsp这个开源软件。
3.3 数据脱敏
关于数据脱敏我们主要关注两部分，一个是敏感数据的存储是否做了加密处理，比如用户的账户密码、商家的卡密，这些都需要在数据落地的地方做加密存储。我们需要通过查询数据库或者文件，确认数据是否做了加密存储。
另外一块就是在传输的过程中，敏感数据是否做了加密处理，比如我们的登录注册功能，在前后端接口交互过程中，密码是否做了加密处理；获取短信相关的业务，接口是否直接将短信做了返回等。我们可以通过浏览器自带的开发者工具F12或者第三方工具fiddler、Charles抓包测试。
3.4 跨目录权限
在商户管理侧，涉及到了商户和子账号的业务需求，子账户是可以定义访问哪些页面的角色。当我们没有给子账户赋权的页面，他是否可以直接通过浏览器中输入url进行访问，这个我们是需要进行测试的。
3.5 跨站脚本
跨站脚本，大家比较熟知的有xss，跨站脚本会导致会话被劫持、敏感信息泄露甚至账户被盗的风险，最简单的方式是在有文本框的地方通过构造js或者html保存，看是否做了转义处理；另外也可以通过带参数的url后面进行js传值进行请求，查看是否执行了js。
3.6 SQL注入
sql注入大家都比较熟悉，在界面上做数据库相关的操作，我们可以构造一些传入参数去改变sql的最终执行逻辑，比如针对查询类的，http://xxx.com/salay/userid=9898,我们可以再后面修改9898为9898 “or 1=1“，这样在最终sql查询中就变成一个始终为真的数据，如果存在注入问题会将所有人的薪资数据暴露出来。sql注入相关的测试我们可以借用sqlmap这个工具。
3.7 越权
越权，简单的理解就是A用户操作了B用户的数据，比如我们在下单过程中，商品A是给会员的购买的，非会员在获取商品ID后，通过下单结构模拟下单商品A，如果能够成功，就证明存在越权的问题，我们可以通过fiddler进行请求截取，然后修改传参进行测试。
3.8 上传下载
文件的上传下载主要有三点：
·一个是对用户磁盘空间的大小限制，比如提供了一个上传功能，用户无限制的上传大容量文件，导致磁盘成本巨大。
·文件类型校验，比如要上传excel的，用户上传了html文件，这个是存在一定的风险的，特别是上传后可以直接访问资源文件，这样用户可以通过上传的html做一些xss的攻击。
·资源下载的安全控制，比如用户下载自己的工资条，是这样一个链接，http://xxx.con/8888.xls,这样就可以联想修改8888这个值为其他值，查看他人的敏感数据。
3.9 服务器端口
服务器端口的测试，对有些自建机房，直接通过物理机进行部署的会很有用处，比如有些不需要使用的端口对外开放了，恶意用户可能利用该端口从事一些非法操作，我们可以通过nmap进行服务器的端口扫描，非必须的端口要关闭。
3.10 业务需求维度
上面的测试项是通用性的规则，结合具体的业务需求，我们也可以产出一些安全测试点，比如针对登录注册的需求，我们从密码强度、验证码可以产出安全测试用例。
针对有些用户类的API接口，我们可以做限流的策略，比如获取短信验证码，我们就要做一些风控策略，否则遇到恶意用户，会造成公司短信成本损失。
四、 结束语
安全是质量保障不可或缺的一环，作为测试人员，我们可以从最基础开始去打造我们的安全测试流程，与其他测试类型一样将安全的思想贯穿在整个软件研发生命周期，做好安全质量内建。也希望大家一起交流你们是如何做安全测试的。
页:
[1]
