其他类型逻辑漏洞

数据包重放漏洞

条件竞争漏洞

订单金额任意修改

接口无限制枚举

支付漏洞

修改商品数量

修改支付状态

修改附属值

越权支付

无限制试用

支付漏洞总结

SRC中的逻辑漏洞总结

其他类型逻辑漏洞

数据包重放漏洞

漏洞介绍：通过数据包重放，可以造成短信轰炸、邮件轰炸、重复提交订单等

漏洞原理：后台未进行相关操作的技术导致数据包重放

漏洞点：短信验证码、邮件校验、提交订单等功能。

修复方案：

修复思路（针对短信、邮件）

构造一个Hashmap<String，short>，存放邮箱或电话号码及对应次数

只要某个邮箱或者电话号码次数够了，就不能继续发送了

或者计算两次发送的时间间隔，时间过短就不继续发送了

通用修复方案：需要建立token机制或验证码机制，一次有效

条件竞争漏洞

漏洞介绍：条件竞争是指一个系统的运行结果依赖于不受控制的事件的先后顺序。当这些不受控制的事件并没有按照开发者想要的方式运行时，就可能会出现bug。尤其在当前我们的系统中大量对资源进行共享，如果处理不当的话，就会产生条件竞争漏洞。说的通俗一点，条件竞争涉及到的就是操作系统中所提到的进程或者线程同步的问题，当一个程序的运行的结果依赖于线程的顺序，处理不当就会发生条件竞争。

漏洞修复

-修复思路：限制同一时间内访问方法的只有单一线程

案列如下：

银行提现：

当我们在手机端进行提现操作时，账户余额为500元，向服务器发送提现500元的请求，提现完毕后账户余额应当清零。

那么如果在我提现成功和它进行清零事件的间隙时间里，我再次发送出提现500元的请求会发生什么呢？条件竞争利用成功的结果就是多了500大洋。

关于条件竞争的漏洞案列大家可以去看这篇文章的Pass-18，我这里就不过多提及了。【文件上传漏洞渗透与攻防（一）_私ははいしゃ敗者です的博客-CSDN博客】

订单金额任意修改

很多中小型的购物网站都存在【订单金额任意修改】漏洞。在提交订单的时候抓取数据包或者直接修改前端代码，然后对订单的金额任意修改。

经常见到的参数大多为： rmb 、value 、amount 、cash 、fee 、money

我们将这些参数修改，比如value=94修改为value=0.01然后放包，然后支付金额便被修改成了0.01元。

关于支付的逻辑漏洞这一块还有很多种思路，比如相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数，无限叠加优惠券等等。

接口无限制枚举

有些关键性的接口因为没有做验证或者其它预防机制，容易遭到爆破攻击。常见账号爆破，密码爆破，验证码爆破，上文都已经提及，还有其他的：

支付漏洞

支付漏洞是 高风险漏洞 也属于 逻辑漏洞，通常是通过 篡改价格、数量、状态、接口、用户名等传参，从而造成 小钱够买大物 甚至可能造成 0元购买商品 等等，凡是 涉及购买、资金等方面的功能处 就有可能存在支付漏洞。

快捷支付原理：商户网站接入支付结果，有两种方式，一种是通过浏览器进行跳转通知，一种是 服务器端异步通知

浏览器跳转通知 ：

基于用户访问的浏览器，如果用户在银行页面支付成功后，直接关闭了页面，并未等待银行跳转到支付结果页面，那么商户网站就收不到支付结果的通知，导致支付结果难以处理。而且浏览器端数据很容易被篡改而降低安全性(这种方式数据经过了客户端浏览器，极大的可能性被第三方恶意修改)

服务器端异步通知：

该方式是支付公司服务器后台直接向用户指定的异步通知URl发送参数，采用POST或者GET的方式。商户网站接受异部参数的URL对应的程序中，要对支付公司返回的支付结果进行签名验证，成功后进行支付逻辑处理，如验证金额、订单信息是否与发起支付时一致，验证正常则对订单进行状态处理或为用户进行网站内入账等。

1、支付三步曲——订购、订单、付款

三个步骤当中的随便一个步骤进行修改价格测试，如果前面两步有验证机制，那么你可在最后一步付款时进行抓包尝试修改金额，如果没有在最后一步做好检验，那么问题就会存在，其修改的金额值可以尝试小数目或者尝试负数。

案列一-淘宝网某处存在严重支付漏洞

1、充值前截图

2、选择充值的套餐

3、使用抓包工具。截图数据包

4、查看结果

案列二、 重放交易

购买成功后，重放其中的请求，竟然可以多次购买商品。

案列：通过网银购买豆元后可以将豆元倍增，修改并重复发起某个http请求可以将豆元倍增。

修改商品数量

没有对购买的数量参数进行限制，导致可随意修改，最常见的修改方式是改成负数或者小数。

案列-某美商城存在支付漏洞

下单

修改数量为-1

修改支付状态

没有对支付状态的值跟实际订单支付状态进行校验，导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功

案列：同程旅交汇低价支付高价订单订单随意修改

获取订单

点击返回修改

提交订单并且抓包

get型数据，查看数据

重点就在这条url:

http://www.17u.net/WDHandler/LineOrder.ashx?action=updateLine&Platform=netlineid=4593689&b2bMemberId=207967&TotalPrice=2750.00&TotalMan=1&TotalChild=0&b2cname=13111112343&b2cphone=13111112343&b2cemail=&remark=&dateText=2015-3-19%200:00:00&orderid=254831

经过测试，这条url，可以在不登录的情况下更新订单，也就是只要知道orderid，就可以更新订单，更重要的是orderid是自增值，很容易推测orderid号。

接下来，我们来更改我刚才下的单，从上面的url里面有两个地方一个是lineid，一个是totalprice，这两个经过尝试是要与网站里面已有的产品一样的，所以我找了一个便宜的产品。

这个产品的id是1806901，价格是50，

然后拿出上面记录的url，修改

http://www.17u.net/WDHandler/LineOrder.ashx?

action=updateLine&Platform=net&lineid=1806901&b2bMemberId=207967&TotalPrice=50&TotalMan=1&TotalChild=0&b2cna

me=13111112343&b2cphone=13111112343&b2cemail=&remark=&dateText=2015-3-19%200:00:00&orderid=254831

然后执行一下，随便在哪执行都行，然后再到订单里面看我们的订单

修改附属值

(1)修改优惠劵金额/数量、(2)修改积分金额、(3)修改运费金额

案列-积分兑换

1、先来看一看随便一个兑换物品的详情，可以发现是积分+金额的

2、点击兑换，拦截数据包，在提交订单转向银联支付页面，修改支付金额为1块钱。

3、支付

越权支付

通过修改一些 特殊传参(如:id,username,openid) 来达到用他人的资金来干购买自己的商品。

案列：小程序越权积分兑换

1、访问积分榜

2、从数据包中可以看到openid泄露，这里其实泄露了很多openid，为了方便只截了一个，接下来配合积分兑换越权使用他人账户兑换物品。

3、Burpsuite中设置，将请求中原有的我的openid替换为排行榜中的第一名的openid

4、进行兑换

5、可以看到地址信息是空的，没有地址无法购买，而添加地址进行的认证是使用的OpenSession进行验证，无法越权上传地址，所以只能通过欺骗前端绕过填写地址，经过数据包读取，发现是生成订单时返回的地址信息addressInfo为空，则可以通过修改订单的响应数据包，将创建订单时返回的地址数据替换为我们的地址数据。

可以看到目前的请求数据包中的openid和响应中的addressinfo都被替换为了我们的原数据包：

替换后的数据包：

无限制试用

通过修改 特殊传参(如:id,pay,test) 来达到无限制试用。

案列：艺龙旅行网严重支付漏洞

1、首先，在艺龙随便下了一个订单，到支付页面，选择信用卡支付

输入正确的卡号，有效期姓名，身份证等相关信息随便输。

居然支付成功了。

那么问题来了

说明这里只判断信用卡有效期即可成功支付

接下来就简单了，我们只要尝试爆破出信用卡的有效期即可

然后发现错误的有效期也能使订单到判定支付是否成功的阶段

所以。下多个订单

随便点击一个订单到支付页面抓包

订单+有效期爆破。隔几秒放过

那么订单都会到判断支付是否成功的阶段，如果订单支付成功，说明有效期是正确的

成功爆破出信用卡有效期并成功支付

支付漏洞总结

1、找到关键的数据包

可能一个支付操作有三四个数据包，我们要对数据包进行挑选。

2、分析数据包

支付数据包中会包含很多的敏感信息（账号，金额，余额，优惠），要尝试对数据包中的各个参数进行分析。

3、不按套路出牌

多去想想开发者没有想到的地方。

4、pc端尝试过，wap端也看看，app也试试

防御方法

1、在后端检查订单的每一个值，包括支付状态；

2、校验价格、数量参数，比如产品数量只能为整数，并限制最大购买数量；

3、与第三方支付平台检查，实际支付的金额是否与订单金额一致；

4、如果给用户退款，要使用原路、原订单退回。比如：退押金，按用户原支付订单原路退回；

5、MD5 加密、解密、数字签名及验证，这个可以有效的避免数据修改，重放攻击中的各种问题；

6、金额超过指定值，进行人工审核等。

SRC中的逻辑漏洞总结

注册：

短信轰炸

验证码安全问题

密码爆破

邮箱轰炸

用户任意注册、批量注册

用户名枚举

XSS（有框的地方就可以尝试插XSS）

登录：

短信轰炸、验证码安全问题、密码爆破、邮箱轰炸

SQL注入

撞库

抓包把password字段修改为空值发送

认证凭证替换、比如返回的数据包中包含账号，修改账号就能登录到其他账号

Cookie仿冒

修改返回包的相关数据，可能会登陆到其他的用户

找回密码：

短信邮箱轰炸、短信邮箱劫持

重置任意用户账户密码、验证码手机用户未统一验证

直接跳过验证步骤

购买支付、充值（要利用抓包去仔细查看每一个可用的参数）

交易金额、数量修改、更换支付模块（比如更换支付的模块金额）

交易信息订单编码/导致信息泄露

整数溢出，int最大值为2147483647，超过最大值

修改充值账户

支付绕过

抽奖活动

刷奖品、积分

并发

优惠卷、代金卷

并发逻辑漏洞（burp批量获取优惠券）

修改优惠券金额、数量

订单信息

订单信息遍历、泄露

订单信息泄露导致用户信息泄露

删出他人订单

会员系统：

修改个人信息上传文件，上传带弹窗的html

如遇上上传xlsx、docx，可能存在XXE，上传恶意的文档盲测

图片上传也可能遇到imagereagick命令执行，上传恶意图片

视频上传如果使用ffmpeg<3.2.4（视频按帧分割成图片），上传恶意avi盲测ssrf

用户横向越权访问、遍历、导致用户信息泄露

SQL注入、个人简历处存储XSS个人信息注册的名称也可以插入XSS

传输过程:

明文传输账户密码

修改信息处无session/token导致csrf

POST/COOKIE注入

评论:

POST注入

存储型XSS

无session/token导致CSRF

验证码问题:

万能验证码

返回包中存在验证码

删除验证码或者cookie中的值可以爆破账号密码

短信轰炸:

一直重放

删除修改cookie，重放数据包

遍历参数发送数据包

手机号后面加空格或者前面加其他的比如+86或者逗号分号等，然后重发数据包

请求参数修改大小写，或者添加请求参数比如&id=1

一个站的登录处可能做了防护，但是再找回密码处可能没有安全防护，或者在注册流程中没有安全防护，所以说多测试接口

如果对手机号一天的次数进行了限制，还可以再发一次短信，DO intercept之后修改为成功回显

水平越权 :

主要登陆后还是修改参数，主要找到多个接口不断测试

关注网页源代码，有时候会有表单，但被bidden（隐藏标签）给隐藏起来了，可以修改返回包然后尝试获取数据检测

多个账号，主要分析请求参数

数据泄露:

再找回密码处，填写数据后抓包查看返回信息，有可能存在敏感数据返回

任意用户密码重置:

目前大部分都是在修改密码处参数修改

有些是前端验证

支付逻辑漏洞:

金额直接传输导致篡改：直接对下单的金额进行修改值，这里可以使用fd或者burp抓包

确定支付之后还可以加入购物车：把商品放入购物车点击下单支付，会跳转到微信，支付宝等第三方支付平台。

请求重放：购买成功之后，继续重放请求，可以让购买的商品一直增加。

请求参数干扰：金钱做了签名认证之后，修改后不通过，但是在里面仍然会有一个参数对金额产生影响导致问题产生。

订单替换：订单替换发生在支付之后的事件处理，同时向服务器发起二次支付请求一个多一个少，支付金额少的，然后支付之后进行替换，告知服务器订单支付完成，并且过程可以反复的回放。

用户替换：在支付过程中发生用户替换现象，首先登陆自己的账户，然后取得另外一个人的账户名等有效信息，在业务流程中用对方的用户名替换自己的用户名，用对方的余额购买完成后，再替换自己的账户名，这样就形成别人的钱买自己的东西

登录绕过:

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

水平越权:

遍历ID-在一些请求中，GET和POST中有明显的ID数字参数（手机号、员工号、账单号、银行卡号、订单号等等）ID替换如果程序对用户标识进行了hash或者加密，而无法破解用的什么方式的话，就无法通过遍历ID来获取其它用户的信息了，此时可以尝试注册两个账号，通过替换两个ID加密后的值，判断程序是否对权限进行了验证，如果没有，也会存在越权问题

垂直越权:

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