业务逻辑漏洞的挖掘

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范围，可以突破默认只能查询六个月的记录。

SRC中的逻辑漏洞总结

1. 注册：
   1. 短信轰炸
   2. 验证码安全问题
   3. 密码爆破
   4. 邮箱轰炸
2. 用户任意注册、批量注册
3. 用户名枚举
4. XSS（有框的地方就可以尝试插XSS）
5. 登录：
   1. 短信轰炸、验证码安全问题、密码爆破、邮箱轰炸
   2. SQL注入
   3. 撞库
   4. 抓包把password字段修改为空值发送
   5. 认证凭证替换、比如返回的数据包中包含账号，修改账号就能登录到其他账号
   6. Cookie仿冒
   7. 修改返回包的相关数据，可能会登陆到其他的用户
6. 找回密码：
   1. 短信邮箱轰炸、短信邮箱劫持
   2. 重置任意用户账户密码、验证码手机用户未统一验证
   3. 直接跳过验证步骤
7. 购买支付、充值（要利用抓包去仔细查看每一个可用的参数）
   1. 交易金额、数量修改、更换支付模块（比如更换支付的模块金额）
   2. 交易信息订单编码/导致信息泄露
   3. 整数溢出，int最大值为2147483647，超过最大值
   4. 修改充值账户
   5. 支付绕过
8. 抽奖活动
   1. 刷奖品、积分
   2. 并发
9. 优惠卷、代金卷
   1. 并发逻辑漏洞（burp批量获取优惠券）
   2. 修改优惠券金额、数量
10. 订单信息
    1. 订单信息遍历、泄露
    2. 订单信息泄露导致用户信息泄露
    3. 删出他人订单
11. 会员系统
    1. 修改个人信息上传文件，上传带弹窗的html
    2. 如遇上上传xlsx、docx，可能存在XXE，上传恶意的文档盲测
    3. 图片上传也可能遇到imagereagick命令执行，上传恶意图片
    4. 视频上传如果使用ffmpeg<3.2.4（视频按帧分割成图片），上传恶意avi盲测ssrf
    5. 用户横向越权访问、遍历、导致用户信息泄露
    6. SQL注入、个人简历处存储XSS个人信息注册的名称也可以插入XSS
12. 传输过程
    1. 明文传输账户密码
    2. 修改信息处无session/token导致csrf
    3. POST/COOKIE注入
13. 评论
    1. POST注入
    2. 存储型XSS
    3. 无session/token导致CSRF
14. 验证码问题
    1. 万能验证码
    2. 返回包中存在验证码
    3. 删除验证码或者cookie中的值可以爆破账号密码
15. 短信轰炸
    1. 一直重放
    2. 删除修改cookie，重放数据包
    3. 遍历参数发送数据包
    4. 手机号后面加空格或者前面加其他的比如+86或者逗号分号等，然后重发数据包
    5. 请求参数修改大小写，或者添加请求参数比如&id=1
    6. 一个站的登录处可能做了防护，但是再找回密码处可能没有安全防护，或者在注册流程中没有安全防护，所以说多测试接口
    7. 如果对手机号一天的次数进行了限制，还可以再发一次短信，DO intercept之后修改为成功回显
16. 水平越权
    1. 主要登陆后还是修改参数，主要找到多个接口不断测试
    2. 关注网页源代码，有时候会有表单，但被bidden（隐藏标签）给隐藏起来了，可以修改返回包然后尝试获取数据检测
    3. 多个账号，主要分析请求参数
17. 数据泄露
    1. 再找回密码处，填写数据后抓包查看返回信息，有可能存在敏感数据返回
18. 任意用户密码重置
    1. 目前大部分都是在修改密码处参数修改
    2. 有些是前端验证

支付逻辑漏洞

1. 边界值问题 : 正常的逻辑是用户购买商品，然后价格累加得到一个总价进行扣款。这个时候就会产生逻辑问题：如果说用户购买的商品是负数了，那么计算的总数就是负数。反过来钱给用户
2. 顺序执行缺陷：正常的逻辑是a-b-c-d 循环渐进的进行流程操作。这个时候就会产生逻辑问题：可以直接从中绕过某一个过程进入到下一步操作。如果说有一项是支付的操作，那么也就会产生支付绕过，如果说有一项是验证机制，就会绕过验证直接进入下一步。
3. 金额直接传输导致篡改：直接对下单的金额进行修改值，这里可以使用fd或者burp抓包
4. 确定支付之后还可以加入购物车：把商品放入购物车点击下单支付，会跳转到微信，支付宝等第三方支付平台。这个时候还可以继续在购物车中加入商品，支付结束之后，商家发放的商品是现在的购物车里面的东西。
5. 请求重放：购买成功之后，继续重放请求，可以让购买的商品一直增加。购买成功之后，会有一个银行对商户网站跳转的过程，如果反复进行操作，有几率会导致商品反复购买和增加，但是不需要付更多的钱。
6. 请求参数干扰：金钱做了签名认证之后，修改后不通过，但是在里面仍然会有一个参数对金额产生影响导致问题产生。
7. 订单替换：订单替换发生在支付之后的事件处理，同时向服务器发起二次支付请求一个多一个少，支付金额少的，然后支付之后进行替换，告知服务器订单支付完成，并且过程可以反复的回放。
8. 欺诈:需要两个收款人，一个是正常的商家，一个是伪造的商家
9. 单位替换：产生在paypal类似的国际支付的场景。
10. 用户替换：在支付过程中发生用户替换现象，首先登陆自己的账户，然后取得另外一个人的账户名等有效信息，在业务流程中用对方的用户名替换自己的用户名，用对方的余额购买完成后，再替换自己的账户名，这样就形成别人的钱买自己的东西
11. 强制攻击：强制攻击发生在暴力破解的情况下，如果一个商家运用一个自己的网店，接入第三方支付接口，由于设计上的不当导致商家与第三方支付约定的密钥Key可以单独被MD5加密，导致可以使用MD5碰撞技术对密钥进行破解，攻击者可以设计简单的密钥加密信息使得MD5加密是可以用MD5碰撞技术进行暴力破解。
12. 秘钥泄漏：内置支付功能的app为了设计上的方便有可能会把Md5或者是RSA的私钥泄漏导致攻击者反编译apk之后获取密钥信息使得交易信息可以被篡改。
13. 函数修改：apk反编译之后的函数修改，可能导致商家在最后一步向支付方提交订单时未验证信息的准确性，仍然被篡改。
14. heart bleed：SSL（安全套接层）协议是使用最为普遍网站加密技术，而OpenSSL则是开源的 SSL 套件，为全球成千上万的web服务器所使用。Web服务器正是通过它来将密钥发送给访客然后在双方的连接之间对信息进行加密。URL中使用 https打头的连接都采用了SSL加密技术。在线购物、网银等活动均采用SSL技术来防止窃密及避免中间人攻击。

该漏洞被归为缓冲过度读取。缓冲过度读取错误是软件可以读取比应该被允许还多的数据。漏洞让特定版本的openSSL成为无需钥匙即可开启的“废锁”，入侵者每次可以翻检户主的64K信息，只要有足够的耐心和时间，就可以翻检足够多的数据，拼凑出户主的银行密码、私信等敏感数据。产生原因：数据在传输的两端是不加密的。一些数据如果在传输过程中不加密则会泄露个人数据等信息。

1. 修改返回包的越权
   1. 修改手机号

一般的逻辑为：认证原手机号-> 填写新手机号-> 提交修改

如果在下一步操作时，没有校验上一步的认证是否成功时，就会存在逻辑缺陷绕过

比如在进行第一步认证原手机号时，随意输入验证码，将response包中的相关字段进行修改，比如0改成1，false改成true，即可绕过第一步验证，进入填写新手机号界面，如果第三步提交修改时没有验证第一步的结果，就会造成逻辑漏洞

1. 登录绕过

部分网站的身份验证放在了前端，因此只需要将response包中的相关字段进行修改，比如0改成1，false改成true，就可以登录任意用户账号

1. 水平越权
   1. 遍历ID

在一些请求中，GET和POST中有明显的ID数字参数（手机号、员工号、账单号、银行卡号、订单号等等），可以尝试进行遍历，如果程序没有对当前权限进行判断，就会存在水平越权问题

1. ID替换

如果程序对用户标识进行了hash或者加密，而无法破解用的什么方式的话，就无法通过遍历ID来获取其它用户的信息了，此时可以尝试注册两个账号，通过替换两个ID加密后的值，判断程序是否对权限进行了验证，如果没有，也会存在越权问题

1. 垂直越权

观察cookie中的session字段，可能某些字段或者参数代表身份，尝试修改