企业业务逻辑常见风险

1、概述

开发人员的安全意识薄弱(只关注功能的实现，而忽略了用户使用过程中个人行为对Web应用程序业务逻辑功能的安全影响)和开发代码的频繁迭代导致了这些平台业务逻辑级的无休止的安全风险。业务逻辑漏洞主要是开发人员业务流程设计的缺陷，不仅限于网络层、系统层、代码层等，如登录认证绕过、事务数据篡改、恶意接口调用(文件上传调用后台API)等都是业务逻辑漏洞。

2、测试流程

• 测试准备
  准备阶段主要包括业务系统的前期熟悉工作。对于白盒测试，可以结合相关的开发文档熟悉相关的系统业务；对于黑盒测试，可以通过实际操作还原业务流程来了解业务。
  ​

• 业务调研
  业务研究主要对业务系统相关人员进行访谈研究，了解业务系统的总体情况，包括部署情况、功能模块、业务流程、数据流、业务逻辑和现有的安全措施等，根据以往的测试实施经验，可以在业务研究之前设计访谈问卷，访谈可以随着对客户业务系统具体情况的深入了解不断调整和更新问卷(这一步骤黑盒测试是可以忽略的)。

• 业务建模
  针对不同行业、不同平台的业务系统，如电商、银行、金融、证券、保险、游戏、社交、招聘等业务系统，识别出其中的高风险业务场景进行建模。
  ​

• 业务流程梳理
  建模完成后，需要对重要业务场景的各个业务模块的业务流程逐一进行梳理，从前到后、业务和支撑系统四个不同维度进行分析，识别业务逻辑，各业务模块的业务数据流和功能字段。

3、业务安全风险内容

业务环节存在的安全风险：
业务链接存在的安全风险是指业务用户可见的业务中存在的安全风险，如注册、登录、密码检索等认证环节，是否有完善的验证码机制、数据一致性验证机制、会话等以及cookie检查机制，是否能够避免captcha绕过、暴力破解、SQL注入等漏洞。

支持系统存在安全风险：
支撑系统存在安全风险，如用户访问控制机制是否完善，是否存在横向越权或纵向越权漏洞等。系统中的加密存储机制是否完善，业务数据是否以明文形式传输。系统使用的业务接口是否可以随意访问/调用，是否可以回放和遍历，接口调用参数是否可以篡改。

业务之间存在安全风险：
业务链接之间存在安全风险，例如系统业务流程是否出现故障，导致业务链接可以被绕过或备份，或者业务请求可以无限期重放。业务链路之间传输的数据是否健壮是一致性检查机制，业务数据是否存在被篡改的风险。

支持系统间的安全风险：
支持系统间的安全风险，如系统间的数据传输是否加密，系统间传输的参数是否可以被篡改等。系统间输入参数的过滤机制是否完善，是否会导致SQL注入、XSS跨站点脚本和代码执行漏洞。

业务链路与支持系统之间的安全风险：
业务链路与支持系统之间的风险，如数据传输是否加密、加密方法是否可以改进、是否采用前端加密、简单MD5编码等不安全的加密方法。多线程并发请求处理机制是否完善，服务器逻辑和数据库读写是否存在导致竞争条件漏洞（QQ刷钻）的时序问题。系统间输入参数的过滤机制是否完善。

4、报告

• 开展测试
  对前期业务流程所识别的风险点进行梳理和识别，并进行相应的测试。

• 撰写报告
  针对企业安全测试过程中发现的风险结果，本文对业务安全测试过程中的风险结果进行了评估和推荐，综合利用了现场的风险程度和风险造成的严重程度，最后完成了测试报告的编写。

5、逻辑漏洞主要位置

（1）、业务数据安全

• 商品支付金额篡改

  在整个业务过程中，电子商务网站需要保护业务数据的完整性和一致性，特别是熟悉如何确保用户客户端和服务之间数据传输的一致性，以及业务系统接口。通常，在订购事务处理过程中，服务器端很容易不对用户提交的业务数据进行强验证，过度依赖客户端提交的业务数据会导致商品数量的篡改漏洞。商品金额篡改测试，通过抓取包修改交易金额等业务流程中的其他字段，如"支付"页面抓取请求中项目的"金额"字段，将其修改为任意金额，并将其提交以查看是否可以使用修改后的金额数据完成业务流程。

  此测试主要针对订单生成过程中由于货物支付金额的不完全验证而引起的业务安全风险点，这通常导致攻击者订购货物的业务逻辑易受攻击，实际支付的金额远远低于订单支付的金额(冰箱为一分钱)。

​

• 前端JS限制绕过验证

许多商品在限制用户购买量时，服务器仅在页面中通过JS脚本限制，没有检查服务器端提交的用户数，通过爬行客户端发送的请求包修改JS端生成的事务数据，如将请求中的项目数更改为大于最大值的限值，以查看业务流程是否能够用异常的业务事务数据完成。

该测试主要针对电子商务平台交易限制机制不完善所造成的一些业务逻辑问题，如在促销活动中限制商品购买量，但对进货前后的数量不进行严格检查，经常被攻击者使用，足以购买多个促销商品，造成企业损失。

​

• 请求重放的测试

请求重放漏洞是电子商务平台业务逻辑漏洞中由设计缺陷引起的一种常见漏洞，通常情况下，第一次购买商品引起的安全问题表现在，参照正常的订货流程请求，完全模拟正常订购业务流程的重放操作，可以实现"一次购买、多次接收"的结果，这与正常的业务逻辑是背道而驰的。

该测试主要针对在电子商务平台订购和交换业务过程中，没有有效的机制来判断每个事务请求的唯一性这一业务逻辑问题。通过这个测试，我们可以验证事务过程中的随机数和时间戳等生成机制是否正常。

• 业务上限测试

业务上限测试主要针对一些电子商务应用在业务处理过程中，由于没有严格验证用户提交的查询范围、订单数量、金额等数据而导致的一些业务逻辑漏洞。

通常，在业务流程中，通过向服务器提交高于或低于预期的数据来验证服务器是否对提交的数据执行了预期的强验证。具有此类漏洞的应用程序通常会查询超出预期的信息、订购或交换超出预期的商品等；此测试主要确定应用程序是否对超出预期业务范围的业务请求做出正确响应

• 订购商品数量被篡改

商品数量篡改测试是通过抓取包来修改业务流程中的订单数量、商品数量等字段，如将请求中的商品数量修改为非预期数量、负数等提交，以检查业务系统是否可以用修改后的数量完成业务流程。

本次测试主要针对商品订购过程中异常交易数据处理缺乏风险控制机制，导致相关业务逻辑漏洞。例如，由于对订购数量和价格缺乏判断而导致的意外结果常常被攻击者利用。

（2）、验证码相关

1、抓包查看验证在Cookie里是否存在
2、验证码重用

（3）、密码找回

• 验证码客户端回显测试

在恢复密码测试中，我们应该注意验证代码在同一个示例中是否得到回音，一些网站程序将选择在响应中回显验证代码，以确定用户输入的验证代码是否与响应验证代码一致，如果验证代码是一致的，则将通过验证。

​

• 验证码暴力破解

恢复密码功能模块通常将用户证书(通常是认证码)发送到用户只能看到的手机号码或邮箱，只要用户不泄露自己的身份验证代码，攻击者就不会利用它，但一些应用程序在验证代码发送功能模块中具有弱认证码位和复杂性，验证代码发送功能模块的次数也没有限制，从而导致验证代码可以被暴力破解和修改任何用户名和密码。

在测试验证代码是否可以通过暴力解密时，您可以首先多次将验证代码发送到您的帐户，以查看验证代码是否正常，例如一次收到的验证代码数很重，4位数。

​

• Reponse状态值修改测试

回复状态值修改测试，即修改请求的响应结果以达到密码重置的目的，带有此漏洞的网站或应用程序由于不合格的验证，经常会导致非常危险的重置密码操作。

此漏洞的攻击通常发生在服务器发送密码重置凭据请求(如true、1、ok、Success等)之后。网站看到回显内容位的特定值后，密码就会被修改。通常，该漏洞的回波值检查是由真正的客户端执行的，因此只需要修改回波。

• Session 覆盖
  网站密码恢复功能的业务逻辑是：用户向手机注册，然后服务器向手机发送验证码短信。用户输入验证码并提交后，进入密码重置页面。
  网站Session覆盖测试如下：

1.需要准备您自己的帐户接受证书（短信验证码）；

2.获取证书验证成功后进入密码重置页面；

3.在新的浏览器标签中重新打开密码恢复页面，然后输入目标手机号码；

4.此时，当前密码是重置会话

帐户已覆盖，再次找到在第二步中打开的重置密码页面以重置目标手机号码。
​

• 弱令牌设计缺陷测试

在密码找回功能中，很多网站将密码恢复页面链接发送到返校用户邮箱。用户只需进入邮箱并打开密码恢复邮箱中的链接即可进入密码重置页面。检索密码的链接通常会添加验证参数以确认链接是否有效。通过验证参数的值是否与数据库生成的值一致，检索密码的链接是有效的。

• 密码找回过程绕过测试

很多网站的密码恢复功能一般包括以下步骤。

1. 用户输入帐号以检索密码；

2。验证证书：向用户发送短信验证码或链接获取密码，用户填写验证码或点击链接进入密码重置页面，证明当前用户就是自己的账户；

3。验证后，用户进入密码重置页面。

在检索密码的逻辑中，第二步是最重要的。不是帐户所有者不能接收验证证书。尝试绕过第二步证书验证，直接进入第三步重置密码

用户需要向服务器发送密码修改请求，服务器通过请求后修改数据库中相应的密码。因此，在测试中，我们首先需要采集三步请求接口，关键是采集最后一步的接口来重置密码，这样就可以直接跳过证书验证接口，尝试直接重置密码。

• 接口参数帐户修改

恢复密码的功能逻辑在用户修改密码接口的提交参数中经常存在传递用户帐户的参数，用户帐户的参数可以作为一个可控变量被篡改，从而导致修改帐户密码证书或修改目标帐户的证书出现偏差，最终导致任何帐户密码修改的漏洞。

通常在密码逻辑中，服务器将要求用户提供要修改的帐户，然后将帐户发送给帐户的所有者才能看到证书。例如，帐户所有者绑定电子邮件或移动电话号码以发送验证代码，或检索密码链接，以便只有帐户所有者才能看到这些凭据。但是，如果服务器不正确控制帐户逻辑，则会导致原始帐户被篡改，服务器将向被篡改的帐户邮箱或移动电话发送凭据，最终导致可能用于重置任何帐户密码的漏洞。

接口参数帐户修改过程测试是拦截前端请求。通过修改请求中的帐户ID、名称或邮箱、手机号码和其他参数，将修改后的数据发送给服务器以进行欺骗，以达到重置密码的目的。