业务逻辑漏洞

1黑客攻击的目标

        ⼀⽅⾯随着社会和科技的发展，购物、社交、P2P、O2O、游戏、招聘等业务纷纷具备了在线⽀付功 能。如电商⽀付系统保存了⽤户⼿机号、姓名、家庭住址，包括⽀付的银⾏卡信息、⽀付密码信息等， 这些都是⿊客感兴趣的敏感信息。攻击者可以利⽤程序员的设计缺陷进⾏交易数据篡改、敏感信息盗 取、资产的窃取等操作。现在的⿊客不在以炫耀技能为主要攻击⽬的，⽽主要以经济利益为⽬的，攻击 的⽬的逐渐转变为趋利化。

        另⼀⽅⾯，如今的业务系统对于传统安全漏洞防护的 技术 、 设备 和 开发框架 越来越成熟，基于传统 漏洞⼊侵也变得越来越困难，增加了⿊客攻击的成本。⽽业务逻辑漏洞可以逃逸各种安全防护，迄今为 ⽌没有很好的解决办法。也是为什么⿊客偏好使⽤业务逻辑漏洞攻击的⼀个原因。

2业务安全测试流程

 测试准备

        准备阶段主要包括 对业务系统的前期熟悉⼯作 。针对⽩盒性质（能够了解到源代码）的测试，可以结合 相关开发⽂档去熟悉相关系统业务；针对⿊盒测试，可通过实际操作还原业务流程的⽅式理解业务。

业务调研

        业务调研阶段主要针对业务系统相关负责⼈进⾏访谈调研，了解业务系统的整体情况，包括部署情况、 功能模块、业务流程、数据流、业务逻辑以及现有的安全措施等内容。根据以往测试实施经验，在业务 调研前可先设计访谈问卷，访谈后可能会随着对客户业务系统具体情况了解的深⼊⽽不断调整、更新问 卷（⿊盒测试此步骤可忽略）。

业务建模

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

业务流程梳理

        建模完成后需要对重要业务场景的各个业务模块逐⼀进⾏业务流程梳理，从前台和后台、业务和⽀撑系 统等4个不同维度进⾏分析，识别各业务模块的业务逻辑、业务数据流和功能字段等。 业务模块的流程梳理主要遵循以下原则

 

 

      #  区分业务主流程和分⽀流程，业务梳理⼯作是围绕主流程进⾏分析的，⽽主流程⼀定是核⼼业务流 程，业务流程重点梳理的对象⾸先应放在核⼼主流程上，务必梳理出业务关键环节；

      #  概括归纳业务分⽀流程，业务分⽀流程往往存在通⽤点，可将具有业务相似性的分⽀流程归纳成某 千锋网络安全学院 ⼀类型的业务流程，⽆须单独对其进⾏测试；

       #识别业务流程数据信息流，特别是业务数据流在交互⽅双⽅之间传输的先后顺序、路径等；

        #识别业务数据流功能字段，识别数据流中包含的重要程度不等的信息，理解这些字段的含义有助于 下阶段⻛险点分析。

通过业务流程的各个阶段梳理出业务流程各个关键环节点。

业务⻛险点识别

        在完成前期不同维度的业务流程梳理⼯作后，针对前台业务应着重关注⽤户界⾯操作每⼀步可能的逻辑 ⻛险和技术⻛险；针对后台业务应着重关注数据安全、数据流转以及处理的⽇志和审计。 业务⻛险点识别应主要关注以下安全⻛险内容。

        #业务环节存在的安全⻛险

                业务环节存在的安全⻛险指的是业务使⽤者可⻅的业务存在的安全⻛ 险，如注册、登录和密码找回等身份认证环节，是否存在完善的验证码机制、数据⼀致性校验机 制、Session 和 Cookie 校验机制等，是否能规避验证码绕过、暴利破解和SQL注⼊等漏洞。

       # ⽀持系统存在的安全⻛险

        ⽀持系统存在的安全⻛险，如⽤户访问控制机制是否完善，是否存在⽔ 平越权或垂直越权漏洞。系统内加密存储机制是否完善，业务数据是否明⽂传输。系统使⽤的业务 接⼝是否可以未授权访问/调⽤，是否可以调⽤重放、遍历，接⼝调⽤参数是否可篡改等。       

        #  业务环节间存在的安全⻛险

         业务环节间存在的安全⻛险，如系统业务流程是否存在乱序，导致某 个业务环节可绕过、回退，或某个业务请求可以⽆限重放。业务环节间传输的数据是否有⼀致性校 验机制，是否存在业务数据可被篡改的⻛险。

      #  ⽀持系统间存在的安全⻛险

        ⽀持系统间存在的安全⻛险，如系统间数据传输是否加密、系统间传 输的参数是否可篡改。系统间输⼊参数的过滤机制是否完善，是否可能导致SQL 注⼊、XSS跨站脚 本和代码执⾏漏洞。

     #   业务环节与⽀持系统间存在的安全⻛险

        业务环节与⽀持系统间存在的⻛险，如数据传输是否加 密、加密⽅式是否完善，是否采⽤前端加密、简单MD5编码等不安全的加密⽅式。系统处理多线 程并发请求的机制是否完善，服务端逻辑与数据库读写是否存在时序问题，导致竞争条件漏洞。系 统间输⼊参数的过滤机制是否完善。

开展测试

对前期业务流程梳理和识别出的⻛险点，进⾏有针对性的测试。

窜写报告

针对业务安全测试过程中发现的⻛险结果进⾏评价和建议，综合评价利⽤场景的⻛险程度和造成影响的 严重程度，最终完成测试报告的编写。

3业务数据安全

商品支付金额篡改

        电商类⽹站在业务流程整个环节，需要对业务数据的完整性和⼀致性进⾏保护，特别是确保在⽤户客户 端与服务端、业务系统接⼝之间的数据传输的⼀致性，通常在订购类交易流程中，容易出现服务器端未 对⽤户提交的业务数据进⾏强制校验，过度信赖客户端提交的业务数据⽽导致的商品⾦额篡改漏洞。商 品⾦额篡改测试，通过抓包修改业务流程中的交易⾦额等字段，例如在⽀付⻚⾯抓取请求中商品的⾦额 字段，修改成任意数额的⾦额并提交，查看能否以修改后的⾦额数据完成业务流程。

        该项测试主要针对订单⽣成的过程中存在商品⽀付⾦额校验不完整⽽产⽣业务安全⻛险点，通常导致攻 击者⽤实际⽀付远低于订单⽀付的⾦额订购商品的业务逻辑漏洞。

1毛钱买个电冰箱

前端JS 限制绕过验证

        很多商品在限制⽤户购买数量时，Web 应⽤仅在⻚⾯通过JS脚本限制，未在服务器端校验⽤户提交的数 量，通过抓取客户端发送的请求包修改JS端⽣成处理的交易数据，如将请求中的商品数量改为⼤于最⼤ 数限制的值，查看能否以⾮正常业务交易数据完成业务流程。

        该项测试主要针对电商平台由于交易限制机制不严谨、不完善⽽导致的⼀些业务逻辑问题。例如，在促 销活动中限制商品购买数量，却未对数量进⾏前、后端严格校验，往往被攻击者所利⽤，购买多个促销 商品，造成商家的损失。

打折商品限制⽤户购买数量，购买多个促销商品。

请求重放测试

        请求重放漏洞是电商平台业务逻辑漏洞中⼀种常⻅的由设计缺陷所引发的漏洞，通常情况下所引发的安 全问题表现在商品⾸次购买成功后，参照订购商品的正常流程请求，进⾏完全模拟正常订购业务流程的 重放操作，可以实现“⼀次购买多次收货”等违背正常业务逻辑的结果。

        该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯⼀性判断缺乏有效机制的业务逻辑 问题，通过该项测试可以验证交易流程中随机数、时间戳等⽣成机制是否正常。

一次购买多次收货

业务上限测试

        业务上限测试主要是针对⼀些电商类应⽤程序在进⾏业务办理流程中，服务端没有对⽤户提交的查询范 围、订单数量、⾦额等数据进⾏严格校验⽽引发的⼀些业务逻辑漏洞。 通常情况下，在业务流程中通过 向服务端提交⾼于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在此类脆弱性 的应⽤程序，通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品等。

        该项测试主要判断应⽤程序是否对业务预期范围外的业务请求做出正确回应。

        历史消费记录。

？id=6
?id=12

商品订购数量篡改

        商品数量篡改测试是通过在业务流程中抓包修改订购商品数量等字段，如将请求中的商品数量修改成任 意⾮预期数额、负数等进⾏提交，查看业务系统能否以修改后的数量完成业务流程。

        该项测试主要针对商品订购的过程中对异常交易数据处理缺乏⻛控机制⽽导致相关业务逻辑漏洞，例如 针对订购中的数量、价格等缺乏判断⽽产⽣意外的结果，往往被攻击者利⽤。

        演例

 使用bp抓包

 修改订单

 

提现走人

 

 

4密码找回安全

验证客户端回显测试

        找回密码测试中要注意验证码是否会回显在响应中，有些⽹站程序会选择将验证码回显在响应中，来判 断⽤户输⼊的验证码是否和响应中的验证码⼀致，如果⼀致就会通过校验。

 验证码出现在响应数据包中。

验证码暴⼒破解

        找回密码功能模块中通常会将⽤户凭证（⼀般为验证码）发送到⽤户⾃⼰才可以看到的⼿机号或者邮箱 中，只要⽤户不泄露⾃⼰的验证码就不会被攻击者利⽤，但是有些应⽤程序在验证码发送功能模块中验 证码位数及复杂性较弱，也没有对验证码使⽤次数做限制⽽导致验证码可被暴⼒枚举并修改任意⽤户密 码。

        在测试验证码是否可以被暴⼒枚举时，可以先将验证码多次发送给⾃⼰的账号，观察验证码是否有规 律，如每次接收到的验证码为纯数字并且是4位数。

Response 状态值修改测试

        Response 状态值修改测试，即修改请求的响应结果来达到密码重置的⽬的，存在这种漏洞的⽹站或者 ⼿机App往往因为校验不严格⽽导致了⾮常危险的重置密码操作。

       这种漏洞的利⽤⽅式通常是在服务端发送某个密码重置的凭证请求后，出现特定的响应值，⽐如

true
1
ok
success
200

Session 覆盖

        找回密码逻辑漏洞测试中也会遇到参数不可控的情况，⽐如要修改的⽤户名或者绑定的⼿机号⽆法在提 交参数时修改，服务端通过读取当前session 会话来判断要修改密码的账号，这种情况下能否对Session 中 ∂的内容做修改以达到任意密码重置的⽬的呢？

        在某⽹站中的找回密码功能中，业务逻辑是：由⽤户使⽤⼿机进⾏注册，然后服务端向⼿机发送验证码 短信，⽤户输⼊验证码提交后，进⼊密码重置⻚⾯。

        #对⽹站中Session 覆盖的测试如下

1. 打开浏览器，访问重置密码⻚⾯，并提交⾃⼰的⼿机号（133），同时浏览器接收SessionID；
2. ⽤⾃⼰的账号（⼿机号）接收凭证（短信验证码）；
3. 获得凭证校验成功后，进⼊密码重置⻚⾯；
4. 在浏览器新标签重新打开找回密码⻚⾯，输⼊⽬标⼿机号(177)，此时服务器就会重新下发
SessionID；
5. 此时当前SessionID 已经被覆盖，重新回到第三步中打开的重置密码⻚⾯即可重置⽬标⼿机号密
码。

        #漏洞原因

1. 在验证码校验之后，没有及时更新SessionID，或者没有及时更新服务器端SESSION 信息
2. SessionID 不仅要与⼿机号绑定，还要与验证码绑定。

弱Token 设计缺陷测试

        在找回密码功能中，很多⽹站会向⽤户邮箱发送找回密码⻚⾯链接。⽤户只需要进⼊邮箱，打开找回密 码邮件中的链接，就可以进⼊密码重置⻚⾯了。找回密码的链接通常会加⼊校验参数来确认链接的有效 性，通过校验参数的值与数据库⽣成的值是否⼀致来判断当前找回密码的链接是否有效。

http://www.xxx.com/findpwd?uid=ajest&token=ajest-2020-0611-1324

密码找回流程绕过测试

很多⽹站的密码找回功能⼀般有以下⼏个步骤

1. ⽤户输⼊找回密码的账号；
2. 校验凭证：向⽤户发送短信验证码或者找回密码链接，⽤户回填验证码或单击链接进⼊密码重置⻚
⾯，以此⽅式证明当前操作⽤户是账号主⼈；
3. 校验成功进⼊重置密码⻚⾯。

       在找回密码逻辑中，第⼆步校验凭证最为重要。不是账号主⼈是⽆法收到校验凭的，试想有没有办法可 以绕过第⼆步凭证校验，直接进⼊第三步重置密码呢？

        ⽤户修改密码需要向服务器发送修改密码请求，服务器通过后再修改数据库中相应的密码，所以在测试 中我们⾸先要收集三个步骤的请求接⼝，重点是收集到最后⼀步重置密码的接⼝，这样我们可以直接跳 过凭证校验的接⼝去尝试直接重置密码。

接⼝参数账号修改

        找回密码功能逻辑中常常会在⽤户修改密码接⼝提交参数中存在传递⽤户账号的参数，⽽⽤户账号参数 作为⼀个可控变量是可以被篡改的，从⽽导致修改账号密码的凭证或修改的⽬标账号出现偏差，最终造成任意账号密码修改的漏洞。

     通常在找回密码逻辑中，服务端会要求⽤户提供要修改的账号，然后给这个账号发送只有账号主⼈才能 看到的凭证。⽐如给这个账号主⼈绑定的邮箱或者⼿机号发送验证码，或者找回密码链接，这样可以保 证只有账号主⼈才可以看到这些凭证。但是如果服务器对账号的控制逻辑不当，就会导致原有账号被篡 改为其他账号，服务器端把凭证发送给篡改后的账号的邮箱或⼿机，最终造成可利⽤凭证重置任意账号 密码的漏洞。

        接⼝参数账号修改流程测试为拦截前端请求，通过修改请求内的账号ID 、名称或者邮箱、⼿机号等参 数，将修改后的数据发送给服务器进⾏欺骗达到密码重置的⽬的。