业务逻辑漏洞总结
一、漏洞简介
业务逻辑漏洞产生的最核心原因，就是在编写程序时，只考虑了常规的操作流程，即“当在A情况下，就会出现B，此时执行C即可”，但是开发者却没有考虑当用户执行了意料之外的X时会发生什么。这种对于异常情况的欠考虑，最终导致了安全漏洞的产生。
应用中的缺陷通常分为两种类型：
- 在不同的应用中有相同的特征
- 与应用程序/业务领域严格相关
其中第一种类型的缺陷，就是类似SQL注入、XSS之类的常规漏洞。这一类漏洞的产生，主要是因为应用程序依赖用户的输入来执行某些重要的功能，但是在用户输入了一些非法字符时，应用程序又未能对于这些输入进行充分的校验和预处理。
而第二种类型的缺陷，则是指的业务逻辑漏洞。它是由错误的应用程序逻辑造成的。业务逻辑缺陷允许攻击者通过绕过应用程序的业务规则来滥用应用程序。这些攻击被伪装成语法上有效的Web请求，这些请求带有恶意意图来违反预期的应用程序逻辑。
随着ORM框架的普及，以及新一代前端框架如AngularJS、Vue等的流行，常规的SQL注入、XSS等漏洞在实际的业务系统中越来越趋于少见。而在攻防演练过程中，可以用于突破系统的漏洞往往集中于在业务逻辑实现层面的漏洞上。
二、漏洞产生的位置
- 登录处
- 业务办理处
- 验证码处
- 支付处
- 密码找回处
三、逻辑漏洞攻击
1 、身份认证安全
1.1、暴力破解
在没有验证码限制或者一次验证码可以多次使用的地方，使用已知用户对密码进行暴力破解或者用一个通用密码对用户进行暴力破解。简单的验证码爆破。
1.2、session & cookie类
会话固定攻击:利用服务器的session不变机制，借他人之手获得认证和授权，冒充他人。
Cookie仿冒:修改cookie中的某个参数可以登录其他用户。
1.3、弱加密
未使用https，是功能测试点，不好利用。
前端加密，用密文去后台校验，并利用smart decode可解
2、业务一致性安全
2.1、手机号篡改
抓包修改手机号码参数为其他号码尝试，例如在办理查询页面，输入自己的号码然后抓包，修改手机号码参数为其他人号码，查看是否能查询其他人的业务。
2.2、邮箱或者用户篡改
抓包修改用户或者邮箱参数为其他用户或者邮箱
2.3、订单id篡改
查看自己的订单id，然后修改id(加减一)查看是否能查看其他订单信息。
2.4、商品编号篡改
例如积分兑换处，100个积分只能换商品编号为001,1000个积分只能换商品编号005,在100积分换商品的时候抓包把换商品的编号修改为005，用低积分换取高积分商品
2.5、用户id篡改
抓包查看自己的用户id，然后修改id(加减1)查看是否能查看其他用户id信息。
3、业务数据篡改
3.1、金额数据篡改
抓包修改金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数据的金额并提交，查看能否以修改后的金额数据完成业务流程。
3.2、商品数量篡改
抓包修改商品数量等子段，将请求中的商品数量修改成任意数额，如负数并提交，查看能否以修改后的数量完成业务流程。
3.3、最大数限制突破
很多商品限制用户购买数量时，服务器仅在页面通过js脚本限制，未在服务器端校验用户提交的数量，通过抓包修改商品最大数限制，将请求中的商品数量改为大于最大数限制的值，查看能否以修改后的数量完成业务流程。
3.4、本地js参数修改
部分应用程序通过Javascript处理用户提交的请求，通过修改Javascript脚本，测试修改后的数据是否影响到用户。
4、密码找回漏洞
密码找回逻辑测试一般流程
i.首先尝试正常密码找回流程，选择不同找回方式，记录所有数据包
ii.分析数据包，找到敏感部分
iii.分析后台找回机制所采用的验证手段
iv.修改数据包验证推测
5、验证码突破
验证码不单单在登录、找密码应用，提交敏感数据的地方也有类似应用，故单独分类，并进一步详情说明。
5.1、验证码暴力破解测试
使用burp对特定的验证码进行暴力破解
5.2、验证码时间、次数测试
抓取携带验证码的数据包不断重复提交，例如:在投诉建议处输入要投诉的内容信息，及验证码参数，此时抓包重复提交数据包，查看历史投诉中是否存在重复提交的参数信息。
5.3、验证码客户端回显测试
当客户端有需要和服务器进行交互，发送验证码时，即可使用firefox按F12调出firebuf就可看到客户端与服务器进行交互的详细信息
5.4、验证码绕过测试
当第一步向第二步跳转时，抓取数包，对验证码进行篡改清空测试，验证该步骤验证码是否可以绕过。
5.5、验证码js绕过
短信验证码验证程序逻辑存在缺陷，业务流程的第一步、第二步，第三步都是放在同一个页面里，验证第一步验证码是通过js来判断的，可以修改验证码在没有获取验证码的情况下可以填写实名信息，并且提交成功。
6、业务授权安全
6.1、未授权访问
非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息。可以尝试在登录某网站前台或后台之后，将相关的页面链接复制于其他浏览器或其他电脑上进行访问，看是否能访问成功。
6.2、越权访问
水平越权
即用户A和用户B属于同一个权限组，水平越权就是用户A可以看到用户B才可以看到的一些内容。一个简单的例子，就是保单管理系统中，每个人都只可以看到自己的保单，如果出现用户A可以查看到用户B的保单的现象，此时就发生了水平越权。
垂直越权
即用户A和用户B属于不同的权限组，如用户A属于普通用户权限组，而用户B属于管理员权限组，垂直越权就是用户A可以看到用户B才可以看到的内容。一个简单的例子，用户A可以看到通讯录界面，用户B可以看到通讯录和用户管理的界面（其中用户管理界面可以看到用户密码）。如果用户A修改一下请求的URL即可以看到作为管理员才可已看到的全部用户密码，此时就发生了垂直越权。
检测思路
出现越权访问漏洞的主要原因，是因为开发人员只是在前端界面进行了简单的菜单隐藏，而没有用统一的服务端拦截器/中间件对于全部URL请求进行权限判断。这样，攻击者只需要在浏览器或者BurpSuite之类的攻击工具中，发出对于指定URL的请求，即可以实现对于特定接口的越权访问。
如果将用户A与他所属的权限组/不同权限组用户群体的惯常访问URL合集进行比对，可以发现有些URL是多个用户都会访问的，而有的URL（或者请求中含有的特定的参数）是各个用户访问时都存在差异的。这类具有差异性的URL即为敏感URL。
当用户A访问了不在惯常访问URL合集内的URL，且此URL为敏感URL，即可以判定为发生了越权访问。
7、业务流程乱序
7.1、顺序执行缺陷
a) 部分网站逻辑可能是先A过程后B过程然后C过程最后D过程
b) 用户控制着他们给应用程序发送的每一个请求，因此能够按照任何顺序进行访问。于是，用户就从B直接进入了D过程，就绕过了C。如果C是支付过程，那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程，就会绕过验证直接进入网站程序了。
8、业务接口调用安全
8.1、重放攻击
在短信、邮件调用业务或生成业务数据环节中(类:短信验证码，邮件验证码，订单生成，评论提交等),对其业务环节进行调用(重放)测试。如果业务经过调用(重放)后被多次生成有效的业务或数据结果。
a) 恶意注册
b) 短信
在测试的过程中，我们发现众多的金融交易平台仅在前端通过JS校验时间来控制短信发送按钮，但后台并未对发送做任何限制，导致可通过重放包的方式大量发送恶意短信
8.2、内容编辑
点击"获取短信验证码",并抓取数据包内容。通过分析数据包，可以发现参数sendData/insrotext的内容有客户端控制，可以修改为攻击者想要发送的内容
9、时效绕过测试
大多有利用的案例发生在验证码以及业务数据的时效范围上，在之前的总结也有人将12306的作为典型，故，单独分类。
9.1、时间刷新缺陷
12306网站的买票业务是每隔5s，票会刷新一次。但是这个时间确实在本地设置的间隔。于是，在控制台就可以将这个时间的关联变量重新设置成1s或者更小，这样刷新的时间就会大幅度缩短(主要更改autoSearchTime本地参数)。
9.2、时间范围测试
针对某些带有时间限制的业务，修改其时间限制范围，例如在某项时间限制范围内查询的业务，修改含有时间明文字段的请求并提交，查看能否绕过时间限制完成业务流程。例如通过更改查询手机网厅的受理记录的month范围，可以突破默认只能查询六个月的记录。
新设置成1s或者更小，这样刷新的时间就会大幅度缩短(主要更改autoSearchTime本地参数)。
9.2、时间范围测试
针对某些带有时间限制的业务，修改其时间限制范围，例如在某项时间限制范围内查询的业务，修改含有时间明文字段的请求并提交，查看能否绕过时间限制完成业务流程。例如通过更改查询手机网厅的受理记录的month范围，可以突破默认只能查询六个月的记录。
参考链接：业务安全漏洞挖掘归纳总结
