业务安全及案例实战

文章目录

业务安全

关于漏洞：

• 注入
• 业务逻辑
• 信息泄露

1. 业务安全概述

1.1 业务安全现状

1.1.1 业务逻辑漏洞

​ 近年来，随着信息化技术的迅速发展和全球一体化进程的不断加快，计算机和网络已经成为与所有人都息息相关的工具和媒介，个人的工作、生活和娱乐，企业的管理，乃至国家的发展和改革都无处其外。信息和互联网带来的不仅仅是便利和高效，大量隐私、敏感和高价值的信息数据和资产，成为恶意攻击者攻击和威胁的主要目标，从早期以极客为核心的黑客黄金时代，到现在利益链驱动的庞大黑色产业，网络安全已经成为任何个人、企业、组织和国家所必须面临的重要问题。网络安全和信息化是事关国家安全和国家发展、事关广大人民群众工作生活的重大战略问题，没有网络安全就没有国家安全，没有信息化就没有现代化。”

​ 随着互联网+的发展，经济形态不断地发生演变。众多传统行业逐步地融入互联网并利用信息通信技术以及互联网平台进行着频繁的商务活动，这些平台（如银行、保险、证券、电商、P2P、O2O、游戏、社交、招聘、航空等)由于涉及大量的金钱、个人信息、交易等重要隐私数据，成为了黑客攻击的首要目标，而因为开发人员安全意识淡薄（只注重实现功能而忽略了在用户使用过程中个人的行为对Wb应用程序的业务逻辑功能的安全性影响)、开发代码频繁迭代导致这些平台业务逻辑层面的安全风险层出不穷。

​ 业务逻辑漏洞主要是开发人员业务流程设计的缺陷，不仅限于网络层、系统层、代码层等。比如登录验证的绕过、交易的数据篡改、接口的恶意调用等，都属于业务逻辑漏洞。

1.1.2 黑客攻击目标

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

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

​ 为了解决业务安全所带来的风险，所以要对业务安全进行审计。

2. 业务安全测试

2.1 业务安全测试流程

2.1.1 测试准备

准备阶段主要包括对业务系统的前期熟悉工作，以了解被测试业务系统的数量、规模和场景等内容。

• 针对白盒测试，可以结合相关开发文档去熟悉相关系统的业务。
• 针对黑盒测试，可通过实际操作还原业务流程的方式理解业务。

2.1.2 业务调研

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

2.1.3 业务建模

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

以电商系统为例：

2.1.4 业务流程梳理

建模完成后需要对重要业务场景的各个业务模块逐一进⾏业务流程梳理，从前台和后台、业务和⽀撑系统等4 个不同维度进⾏分析，识别各业务模块的业务逻辑、业务数据流和功能字段（传参点）等。

业务模块的流程梳理主要遵循以下原则：

• 区分业务主流程和分⽀流程，业务梳理⼯作是围绕主流程进⾏分析的，而主流程一定是核⼼业务流程，业务流程重点梳理的对象⾸先应放在核⼼主流程上，务必梳理出业务关键环节。
• 概括归纳业务分⽀流程，业务分⽀流程往往存在通⽤点，可将具有业务相似性的分⽀流程归纳成某一类型的业务流程，⽆须单独对其进⾏测试。
• 识别业务流程数据信息流，特别是业务数据流在交互⽅双⽅之间传输的先后顺序、路径等。
• 识别业务数据流功能字段，识别数据流中包含的重要程度不等的信息，理解这些字段的含义有助于下阶段⻛险点分析。

2.1.5 业务风险点识别

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

业务⻛险点识别应主要关注以下安全⻛险内容。

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

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

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

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

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

2.1.6 开展测试

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

2.1.7 撰写报告

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

3. 业务安全经典场景

3.1 业务数据安全

3.1.1 商品支付金额篡改

典型案例：

• 1毛钱买电冰箱

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

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

案例1

靶场链接地址：Dashboard | Web Security Academy - PortSwigger。

使用提供的用户名和密码进行登录

wiener:peter

登录后查看我们的余额现在是100元

然后回到主页选择夹克进行购买

将夹克先添加到购物车中

然后到购物车中直接支付发现余额不足

这里直接使用bp抓取数据包，这里抓取的是添加购物车时的数据包。

修改商品金额后点击放包。

这样就可以完成购买了。

第二题

和上题一样先选择夹克添加购物车，但是这里在添加购物车的时候抓取数据包，然后将商品的数量修改为一个负数。

这个时候回到购物车查看，商品的总金额变成了一个负数。

然后我们添加一些别的商品，使得总金额回到一个我们可以支付的价格。

这里我添加了15个91.01元的商品

查看购物车，发现总金额变成了28元，我们这里直接下单统统拿下。

购买成功！

案例2

登录大米CMS后查看余额为0元

选择产品展示，点击购买

这里选择站内付款

然后在提交订单的时候进行抓包，将金额修改为一个负数

放包后显示订单成功

然后返回查看充值模块，发现我们的余额由原先的0元变为了6000元。

3.1.2 前端JS限制绕过

典型案例：

绕过JS 限制，购买多个打折商品

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

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

3.1.3 请求存放测试

典型案例：

一次购买，多次收货

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

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

3.1.4 业务上限测试

典型案例：

⽆限制查询历史消费记录。

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

3.1.5 商品订购数量篡改

典型案例：

damicms_5.4_⽹上商城任意商品购买

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

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

3.2 密码找回安全

• 用户提交修改密码请求。
• 账号认证：服务器发送唯一D(例如短信验证码)只有账户所有者才能看的地方，完成身份验证。
• 身份验证：用户提交验证码完成身份验证。
• 修改密码：用户修改密码。

3.2.1 验证码客户端回显测试

典型场景：

• 任意用户登录

使用验证码的场景：

• 人机验证：防止机器操作，爆破表单。
• 唯一凭据：唯一性判断，任意账户登录。

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

3.2.2 验证暴力破解

典型案例：

验证码⽆使⽤次数限制

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

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

3.2.3 Response 状态值修改测试

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

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

• true
• 1
• ok
• success
• 200
• …

⽹站看到回显内容为特定值后即修改密码或者登陆，通常这种漏洞的回显值校验是在客⼾端进⾏的，所以只需要修改服务器的响应数据包即可。

3.2.4 Session覆盖

Session ID 也叫会话ID，服务器对浏览器客⼾端⽤⼾⾝份进⾏唯一性标志。

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

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

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

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

漏洞原因：

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

3.2.5 弱Token设计缺陷测试

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

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

3.2.6 密码找回流程绕过测试

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

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

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

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

3.2.7 接口参数账号修改

典型案例：

metinfo_4.0 任意账号密码重置

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

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

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

案例

Metinfo_4.0下载链接MetInfo历史版本与文件。

管理员登录网站可以管理后台

在网站的首页，我们注册一个wuhu账号密码123456

然后修改密码。

使用bp抓取修改密码的数据包信息

这里我们可以修改密码，当然也可以修改用户名，将用户名修改为admin管理员用户。

修改成功后，回到管理员账户进行登录。使用原先的密码123456登录，登录失败。

然后使用我们修改后的密码654321进行登录登录成功