针对业务测试人员不仅仅要关注功能测试，业务安全测试也已经成为测试的一部分，特梳理如下业务安全测试指引，文中提到了一些常见案例，也欢迎大家留言说说你都遇到过哪些漏洞案例？也希望本文能够对你有所帮助。

目   录

1 目的

2 范围

3 安全标准介绍

3.1 OWASP--安全标准

3.2 OWASP TOP 10

4 常见漏洞分类

4.1 破坏访问控制（越权漏洞）

4.1.1 查看订单信息，不存在越权漏洞

4.1.2 菜单访问/操作，不存在越权漏洞

4.2 加密失败/敏感信息泄露

4.2.1 敏感信息的明文传输

4.2.2 敏感信息接口返回未打码

4.3 注入

4.3.1 跨站脚本攻击（XSS）漏洞

4.4 不安全设计

4.4.1 短信轰炸

4.4.2 暴力破解

4.4.3 不安全的重定向

4.4.4 任意文件上传

4.4.5 篡改数据

4.4.6 并发导致库存超限

5 指引建议

1 目的

本文档是指导业务测试人员进行业务安全测试的开展，通过本指引指导提升业务安全测试意识，从而降低业务安全漏洞。

2 范围

本指引适用于互联网项目的业务安全测试活动。

3 安全标准介绍

3.1 OWASP--安全标准

开源Web应用安全项目（OWASP）是一个开放的社区，

致力于帮助各企业组织开发、购买和维护可信任的应用程序。

OWASP Top 10项目的最初目标只是为了提高开发人员和管理人员的安全意识，但它已经成为了实际的应用安全标准。

3.2 OWASP Top 10

• Broken Access Control（破坏访问控制：越权漏洞）

• Cryptographic Failures(加密失败/敏感信息泄露）

• Injection （注入：SQL注入、跨站点脚本攻击（XSS））

• Insecure Design（不安全设计：暴力破解）

• Security Misconfiguration（安全配置错误）

• Vulnerable and Outdated Components（脆弱和过时的组件）

• Identification and Authentication Failures（身份验证失败）

• Software and Data Integrity Failures（软件和数据完整性故障）

• Security Logging and Monitoring Failures（安全日志和监控失败）

• Server-Side Request Forgery（服务器端请求伪造（SSRF））

可参考：https://owasp.org/Top10/A01_2021-Broken_Access_Control/

4 常见漏洞分类

4.1 破坏访问控制（越权漏洞）

4.1.1 查看订单信息，不存在越权漏洞

测试要点：

A用户查看orderid=100的信息，orderid=100是属于A用户的订单信息，A有权限访问；

测试准备：

抓包工具，测试环境正常运行，两个无相关性的同级别用户A、B

测试步骤：

1. 用户A登录，查看A用户的订单详情并抓取数据包，得到订单id；

2. 用户A退出，登录用户B，查看B用户的某一个订单详情时，抓取数据包，将id改成A用户的id进行请求；

预期结果：

用户只能访问自己权限内的相关内容，无法查看其他用户的相关内容；

修复建议：

增加身份校验；

4.1.2 菜单访问/操作，不存在越权漏洞

测试要点：

给A用户配置了某一个菜单权限，B用户没有配置此菜单权限，直接访问菜单链接，A有权访问，B无权访问；

测试准备：

抓包工具，测试环境正常运行，两个菜单权限不同的用户A、B

测试步骤：

1. 菜单C权限配置给了用户A，用户A访问菜单C，抓取菜单C的链接及相关操作数据包；

2. 用户A退出，登录用户B，用户B无菜单C权限，浏览器直接访问菜单C的链接，并且使用用户B的cookie调用之前A用户相关的操作；

预期结果：

用户B不能访问菜单C的链接且不能调用菜单C对应相关的接口；

修复建议：

控制但不仅限菜单不可见，还要针对此菜单接口的所有操作进行角色/权限的相关控制；

4.2 加密失败/敏感信息泄露

4.2.1敏感信息的明文传输

测试要点：

站点登录时，密码不应该是明文，需要做加密处理；

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 找到登录页面，输入账号密码，进行登录；

2. 抓取数据包，查看入参；

预期结果：

账号和密码都是加密的；

修复建议：

在传输之前使用可靠的加密方案加密数据；

4.2.2 敏感信息接口返回未打码

测试要点：

是否存在接口返回或展示用户较敏感信息，比如页面展示要求手机号/银行卡等信息部分打码，同时接口返回的数据也是打码的；

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 进入相关页面，比如个人银行卡管理列表页面；

2. 页面展示银行卡号，并抓取数据包看返回数据是否打码；

预期结果：

敏感数据应做打码处理；

修复建议：

页面展示及接口返回的数据都应该打码；

4.3注入

4.3.1跨站脚本攻击（XSS）漏洞

测试要点：

存在输入输出内容的页面，进行脚本的输入，被拦截或输入成功后，html代码不执行；A用户在投保单录入页面填写地址信息为

"><img src=1 οnerrοr=alert(1)>进行出单，A用户在订单详细页查看地址信息，地址信息为html代码，未执行成功。

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 找到存在输入框及存储行为的地方，如投保单录入页面填写地址信息输入框，录入正常的内容：卡园3号，保存提交，抓取数据包，拦截将卡园3号修改为："><img src=1 οnerrοr=alert(1)>，重新提交；

2. 出单后，进入订单详情页面查看地址信息；

预期结果：接口过滤禁止提交，或者在页面展示输出时被转义；

修复建议：增加特殊字符及标签过滤；

4.4不安全设计

4.4.1短信轰炸

测试要点：

登录/注册等功能涉及到发送短信的页面，不应该存在可以不断调用发送短信接口给手机号不断发送短信的情况，应该有图形验证码、单IP请求次数限制、单用户发送次数限制等方案避免短信轰炸；

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 打开抓包工具，找到可发送短信的功能页面，触发短信发送请求，抓取数据包，使用抓包工具回放多次（比如fiddler选中对应的请求，快捷键shift+u，输入回放次数）；

2. 是否会发送成功多次；

预期结果：

不应该发送成功多次，应该有图形验证码且验证码一次有效；

修复建议：有图形验证码且一次有效，单IP请求次数限制，单用户发送请求频次限制等；

4.4.2暴力破解

测试要点：

登录接口不断的修改验证码或者密码，进行发送登录接口重试，不应该一直可以重试，应该有图形验证码、失败重试次数限制等方案避免账号被暴力破解；

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 打开抓包工具，找到登录密码页面，输入正确账号错误密码登录，抓取数据包；

2. 尝试修改数据包中的密码，不断发请求；

预期结果：

登录具有登录控制及锁定策略；

修复建议：

增加图形验证码，失败重试次数达到上线后锁定账号等；

4.4.3不安全的重定向

测试要点：

url重定向地址修改为其他网站地址后，不应该重定向到其他网站，避免被钓鱼页面诱导；

测试准备：

测试环境正常运行

测试步骤：

1. 找到含有页面跳转的url，如登录界面url：https://passport.jd.com/new/login.aspx?ReturnUrl=https%3A%2F%2Fwww.jd.com%2F；

2. 在该url后有个ReturnUrl字段，https%3A%2F%2Fwww.jd.com%2F 做了1次URLEncode，将该字符串替换成：https%3A%2F%2Fwww.baidu.com%2F，即：https://passport.jd.com/new/login.aspx?ReturnUrl= https%3A%2F%2Fwww.baidu.com%2F；

3. 将上面组合后的url地址输入到地址栏访问，然后登录观察是否跳转到百度页面？

预期结果：

页面正常登录，不跳转到百度页面，或者url中携带的是非京东的地址就被过滤掉了；

修复建议：

增加跳转页面白名单限制；

4.4.4任意文件上传

测试要点：

涉及到文件上传的地方，要有对应上传限制，避免上传非法文件到服务器；

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 检查上传点是否有严格的类型限制，只接受某种类型或几种类型的文件；

2. 检查上传点是否有大小容量限制，如只接受5M以下的图片等；

3. 检查上传点对于文件类型及大小的限制是否有后台验证：使用抓包工具拦截上传文件的数据包，将数据包中的文件名改为不符合上传文件要求的文件（如类型，大小不符合等），重放请求，观察不符合要求的文件是否上传成功？

预期结果：

所有上传点后端必须有类型、大小的上传限制；

修复建议：

增加文件大小、类型强校验，且后端重命名不可推测的文件名；

4.4.5篡改数据

测试要点：

篡改实物或虚拟商品的价格，花更少的钱甚至不花钱获得想要的商品；

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 用户购买商品，假如充值100元的游戏币，在前往第三方支付跳转时，拦截抓取数据包，将金额篡改成0.01，重放请求；

2. 看是否能够支付或者支付成功后，是否以少的支付金额获得了100元等值的游戏币；

预期结果：修改不成功或无法支付；

修复建议：请求加密，及服务端对实际支付的金额等相关信息要做严格校验；

4.4.6并发导致库存超限

测试要点：

有限制库存的场景，比如积分兑换商品一人只能兑换一份/抽奖活动时一人只能抽一次/多人抢最后一个库存，都不能出现超限的情况；

测试准备：

抓包工具，测试环境正常运行；

测试步骤：

1. 找到限制库存的类似场景，比如在抽奖活动时，一个人只能抽一次机会；

2. 用户抽奖时，拦截抓取抽奖请求数据包，设置回放次数，比如fiddler快捷键shift+u，输入回放次数20，一次性全部放过请求，观察数据返回及抽奖记录；

预期结果：

21次回访请求记录中，有且只有一次是参与成功的，不能有多次；

修复建议：

要考虑并发场景；

5 指引建议

参考以上漏洞分类及案例，在编写测试分析的时候新增业务安全测试模块的分析，是否有涉及到类似的功能，进行业务安全测试点的梳理。

最后文中提到的抓包工具，如果还有不太熟悉的可以访问旧文：Fiddler抓包工具入门及常用功能详解，如果此文对你有启发，请转给身边的同事、朋友，谢谢！