目录
业务安全 –业务逻辑漏洞
业务安全概述;
业务安全测试流程：
业务数据安全
商品支付金额篡改
前端JS限制绕过验证
请求重放测试
业务上线测试
*商品订购数量篡改
密码找回安全
注入
业务逻辑
信息泄露
业务安全概述;
简单讲，随着社会发展，越来越多的行业都开始发展互联网业务，利用信息通信性技术以及互联网平台进行商务互动（金钱交易）。如：银行、保险、证券电商、P2P、O2O、游戏、社交、招聘、航空等。涉及金钱、个人信息、交易、等重要隐私数据，成为黑客攻击的目标。
(业务逻辑漏洞主要是开发人员业务流程设计的缺陷，不仅限于网络层、系统层、代码层等。例登陆验证码绕过、交易中的数据被篡改、接口的恶意调用等，都属于业务逻辑漏洞)。
注：业务逻辑漏洞可以逃逸各种安全防护，迄今为⽌没有很好的解决办法。也是为什么⿊客偏好使⽤业务逻辑漏洞攻击的⼀个原因。
业务安全测试流程：
准备>>调研>>场景建模>>流程梳理>>风险点识别>>业务风险点识别>>开展测试>>撰写报告
业务数据安全
商品支付金额篡改
电商类网站在业务流程整个环节，需要对业务数据的完整性和一致性进行保护，特别是在确保在用户客户端与服务端、业务系统接口之间的数据传输的一致性。通常在订购类交易流程中，容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户提交的业务数据而导致的商品金额篡改漏洞。
商品金额篡改漏洞测试，通过BP抓包修改业务流程中的交易金额等字段，例在支付页面抓取金额字段，修改成任意金额提交，查看是否是修改后的金额数据完成业务流程。
测试作用：
主要针对订单⽣成的过程中存在商品⽀付⾦额校验不完整⽽产⽣业务安全⻛险点，通常导致攻击者⽤实际⽀付远低于订单⽀付的⾦额订购商品的业务逻辑漏洞。
现实案例：一毛钱买冰箱。
前端JS限制绕过验证
很多商品在限制用户购买数量时，Web应用仅在页面通过JS脚本限制，未在服务端校验用户提交的数量。
我们可以通过BP抓取苦户端发送的请求包修改JS端生成处理的交易数据，将请求中的商品数量改成大于最大限制的值，看能否以非正常业务交易数据完成业务流程。
测试作用：主要针对电商平台由于交易限制机制不严谨、不完善⽽导致的⼀些业务逻辑问题。例如，在促销活动中限制商品购买数量，却未对数量进⾏前、后端严格校验，往往被攻击者所利⽤，购买多个促销商品，造成商家的损失。
现实案例：打折商品限制⽤户购买数量，购买多个促销商品。
请求重放测试
是电商平台业务逻辑漏洞中⼀种常⻅的由设计缺陷所引发的漏洞，通常情况下所引发的安全问题表现在商品⾸次购买成功后，参照订购商品的正常流程请求，进⾏完全模拟正常订购业务流程的重放操作，可以实现“⼀次购买多次收货”等违背正常业务逻辑的结果。
测试作用：该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯⼀性判断缺乏有效机制的业务逻辑问题，通过该项测试可以验证交易流程中随机数、时间戳等⽣成机制是否正常。
现实案例：一次购买多次发货。
业务上线测试
业务上限测试主要是针对⼀些电商类应⽤程序在进⾏业务办理流程中，服务端没有对⽤户提交的查询范围、订单数量、⾦额等数据进⾏严格校验⽽引发的⼀些业务逻辑漏洞。
*商品订购数量篡改
该项测试主要针对商品订购的过程中对异常交易数据处理缺乏⻛控机制⽽导致相关业务逻辑漏洞，例如针对订购中的数量、价格等缺乏判断⽽产⽣意外的结果，往往被攻击者利⽤。
实战：damiCMSV5.4网上商城任意商品购买
成功！！！！
密码找回安全
☺ 验证码客户端回显测试
找回密码测试中要注意验证码是否会回显在响应中，有些⽹站程序会选择将验证码回显在响应中，来判断⽤户输⼊的验证码是否和响应中的验证码⼀致，如果⼀致就会通过校验。
☺ 验证码暴力破解
用户登录或者修改密码时验证码使用次数没有受限制，就会被HEIKE暴力破解并修改任意用户密码。
☺ Response状态值修改测试
Response 状态值修改测试，即修改请求的响应结果来达到密码重置的⽬的，存在这种漏洞的⽹站或者⼿机App往往因为校验不严格⽽导致了⾮常危险的重置密码操作。
这种漏洞的利⽤⽅式通常是在服务端发送某个密码重置的凭证请求后，出现特定的响应值，⽐如
| true 1 ok success 200 |
注：通常这种漏洞的回显值校验是在客户端进⾏的，所以只需要修改服务器的响应数据包即可。
☺ * Session覆盖
业务逻辑是：由⽤户使⽤⼿机进⾏注册，然后服务端向⼿机发送验证码
短信，⽤户输⼊验证码提交后，进⼊密码重置⻚⾯。
测试：
1. 打开浏览器，访问重置密码⻚⾯，并提交⾃⼰的⼿机号（例：133），同时浏览器接收SessionID；
2. ⽤⾃⼰的账号（⼿机号）接收凭证（短信验证码）；
3. 获得凭证校验成功后，进⼊密码重置⻚⾯；
4. 在浏览器新标签重新打开找回密码⻚⾯，输⼊⽬标⼿机号(例：177)，此时服务器就会重新下发SessionID；
5. 此时当前SessionID 已经被覆盖，重新回到第三步中打开的重置密码⻚⾯即可重置⽬标⼿机号密码。
漏洞原因：
- 验证码校验之后，没有及时更新SessionID,或者没有及时更新服务器端Session信息。
- SessionID么有与手机号绑定还木有验证码绑定。
☺ 弱Token设计缺陷测试
在找回密码功能中，很多⽹站会向⽤户邮箱发送找回密码⻚⾯链接。⽤户只需要进⼊邮箱，打开找回密码邮件中的链接，就可以进⼊密码重置⻚⾯了。找回密码的链接通常会加⼊校验参数来确认链接的有校性，通过校验参数的值与数据库⽣成的值是否⼀致来判断当前找回密码的链接是否有效。
☺ 密码找回流程绕过测试
网站的密码找回功能一般有以下几个步骤：
- 用户输入找回密码的账号：
- 校验凭证：向用户发送短信验证码或者找回密码链接，用户回填验证码或单击链接进入密码重置页面，以此方式证明当前操作用户是账号主人：
- 校验成功进入重置密码页面。
⽤户修改密码需要向服务器发送修改密码请求，服务器通过后再修改数据库中相应的密码，所以在测试中我们⾸先要收集三个步骤的请求接⼝，重点是收集到最后⼀步重置密码的接⼝，这样我们可以直接跳过凭证校验的接⼝去尝试直接重置密码。
☺ 接口参数账号修改
找回密码功能逻辑中常常会在用户修改密码接口提交参数中存在用户账号的参数，而用户参数作为一个可控变量是可以被篡改，从而导致修改账号密码的凭证或修改的目标账号出现偏差，最终造成任意账号密码修改的漏洞。
接⼝参数账号修改流程测试为拦截前端请求，通过修改请求内的账号ID 、名称或者邮箱、⼿机号等参数，将修改后的数据发送给服务器进⾏欺骗达到密码重置的⽬的
