web漏洞支付总结

付款系统漏洞长期以来就是说是高危，对企业来说伤害很大，对客户来说一样伤害也大。就例如我用别人帐户开展消費，这也属于付款系统漏洞中的滥用权力问题。那么付款系统漏洞通常存在在哪些因素呢，根据姓名就知道，一切牵涉订购、资产等方面的功能处总有可能存在付款问题。本稿子将分类管理来开展讲述付款系统漏洞之中的哪些构思。

最先说下付款问题的构思

0x01   改动付款价位

在付款之中，订购货物通常分成三过程：购买、确认信息、支付。

那么这个改动价位具体化是改动哪几步时的价位呢？毫无疑问，你会你在3个过程之中的随意一个过程开展改动价格测试，假如前边二步有认证措施，那么你啊在末尾几步支付时开展抓包尝试改动数额，要是在末尾几步搞好检查，那么问题就会存在，其改动的数额值你会尝试小数目或者尝试负数。

这儿我找到有关事例：

①：htpp://bbs.ichunqiu.Com/forum.Python?整合包=viewthread&tid=8236

②：htpp://bbs.ichunqiu.Com/forum.Python?整合包=viewthread&tid=21478

③：.com://www.anquan.us/static/bugs/wooyun-2018-0174748.hmtl

0x02   改动付款状态

这个问题我隐隐约约的碰到过，以前在找有关基本资料的时候发现了一段文字讲的是改动付款状态为已付款状态这样的构思，然后挑起了我的想起，这个问题是没有对付款状态的值跟真实定单付款状态开展校正，导致点一下付款时抓包改动决定付款或未付款的主要参数为付款状态的值从而达到验证成功。

这儿是一个事例，虽然其稿子创作者检测不成功了，但我认为构思是十分非常好的，事例：

①：htpp://bbs.ichunqiu.Com/forum.Python?整合包=viewthread&tid=28151

0x03   改动订购总数

在付款的过程中，总数也直接决定着价位，例如：1个总数货物相关联的是100，2个统计数据就是说150，那么当我们改动这个值总数数值负数时，那么其数额也会转变成负数，末尾就会导致付款问题的造成。

0x04   改动附设值

这儿就是我自己想的一个词，例如在很多订购的时候能够运用積分或者优惠券等等开展充当数额支付，那么就容易存在的问题。这里把我附设值分成两类开展讲述。

①：改动优惠券数额

优惠券其主要都是优惠待遇一小半，通常用优惠券开展消費通常出现在下一个过程之中：核对订购信息，在这个过程网页页面之中，你会选择有关优惠券，然后直接改动数额超过或相当于货物的价位就可以，或者直接改动其为负数开展尝试，末尾开展付款，假如对其实没有多方面认证，那么问题就会造成，直接验证成功。

②：改动优惠券数额及业务逻辑问题

可能你看到这个主题词会想起，你不是上一个讲的就是说这个改动优惠券数额的问题嘛？为啥需要再讲两遍这个？请再次看！

以前碰到过这个系统漏洞，这个系统漏洞也是逻辑性问题导致了成功失败运用，一样在是在继集核对订购信息之中有可选择优惠券开展付款，但是，当我们改动其优惠券数值随意值或负数想要付款的时候，会回显支付失败，或者数额有误等一些显示，可能这时候很多套子会很心寒然后就会来任何点找问题了，但当我们找寻用户中心，点一下订单信息，假如存在这个逻辑性问题，那么这时在你不久改动优惠券数额后点一下接下来付款的时候，其实此刻就已经造成了定单了，你一直在订单信息内就可以看付款数额为0，或许不久改动了优惠券数额嘛，然后你点一下付款就可以验证成功。

当然，这儿需要说下小窍门，有可能会支付失败，但是当你找寻的这个问题是一个通常业务流程分站名，假如有内置的一个钱夹功能，那么我也可以运用这个只带的钱夹功能去付款这个定单，而不要运用任何付款类形，那么就可以验证成功！

③：改动積分数额

一些网站有積分，例如你消費多少，评伦多少就可以有着一定的積分总数，这个積分可以在你支付的时候开展打折其定单数额，假如这个没有搞好積分数额的校正，那么当我们在付款之中选择用積分为帐户减一些数额的时候，可以抓包改动其積分数额为随意数或负数额，然后可0元验证成功。

有关事例：.com://www.anquan.us/static/bugs/wooyun-2014年-0139556.hmtl

0x05   改动支付接口

例如一些网站支技很各种付款，例如自己的支付工具，三方的支付工具，然后每一支付接口值相差太大，假如逻辑设计不善，当你随意选择一个点一下付款时开展抓包，然后改动其支付接口为一个未找到的插口，假如没搞好未找到插口有关处置，那么这时就会验证成功。

0x06   多沉重命名付款

很早以前仿佛也看到过有关的事例，最先去造成两个定单，这两个定单产品相差太大的，其价位相差太大，假如服务器端没有搞好这有关的认证，那么在付款的过程之中抓包，改动其定单数值其它定单值，末尾付款，这时候就可以用定单一的付款价位购到定单而的货物。

0x07   反复付款

这个其实只是付款之中的一个别类，但是这个构思新奇，因此我也列了出来了，例如一些贸易市场有个类似试用期品牌或者任何，这个试用期品牌可以依赖每日签到获得，而这个品牌的作用可以去试用期一些货物，在你开展试用期的时候会扣出你的试用期品牌，当我们试用期进行或者积极撤销试用期时，试用期品牌会回到到帐户之中，你不知道，每日签到获得的品牌确实非常少，且假如想试用期好点的货物那么品牌的总数就至关重要了。

这儿的问题就是说要是开展对定单多沉递交的校正，那么就可导致无限定刷品牌，例如，你试用期时抓包，然后你每一次试用期都会造成一个订单编号，然后运用刚捉到的数据文件开展大批量递交，我也可以看每一次递交的订单编号相差太大，然后这时候你再看定单可以看相同货物的成千上万定单，但试用期品牌数只扣了你第一位实验时的品牌数，那么这时候你申报大批量撤出试用期，那么这么多定单，每退一个就会退相对的品牌总数到帐户之中，这就分为了无限定刷得问题。

0x08   最小额支付

在很多套子检测付款的系统漏洞时候，改动的数额往往都是0.02等或者负数，想对你说这比较容易错失去一些不确定性的付款问题，我也深有体会，在发掘付款系统漏洞的过程之中，就碰到过，直至第二次再次检验时才发现，例如一些网站有点卷或者積分什么就等于付款可以用这些付款，那么在冲值的时候，例如：10元相关联的積分数值100、50相关联的是6000、100相关联的是50000。

这个问题假如你一直在冲值时开展改动其付款数额为负数或者0.02等是会显视支付失败的，但是当你改动其数额为1.00，那么付款就会成功失败，也就用1元订购到随意最该積分总数了，这是怎么回事？

其实你一直在检测过程之中仔细点就可以特好发现的，这儿最少就是说1元，1元相关联100積分，也许假如改动为0.02，那么相关联的積分就是说空值了，因此会显视不成功，而当我们改动为1元，那么1元这个支付接口是存在的，其后占地面成绩为任何数额的積分数，然后自动跳转以往付款就会以1元订购到比它多一些的積分总数，还可以是随意積分值。

0x09   数值最高值付款问题

很早以前也是看到过有关的事例，一些网站例如你订购货物，这儿有2个构思改动值，1是直接改动付款数额数值最高值，例如999999999，或者改动附设值，如优惠卷，積分等为999999999，假如这儿逻辑设计不太好，那么其付款数额会转变成0。

0x10   滥用权力付款

这个问题很早以前以前有过，现在可能非常少存在这类问题，在付款之中会出现当今客户的Id，例如：username=XXXXX，要是多方面认证，其付款也是一次付款没有要求输入验证码什么的措施，那么就可以改动这个客户Id为任何客户Id，达到用普通用户的账户开展付款你的货物。

0x11   无限定试用期

一些网站的一些货物，例如云全线产品支技试用期，试用期阶段通常为7天或者30天，一个帐户必须试用期一次，试用期过后不能再试用期，但假如这个试用期插口会搞好分派那么比较容易导致问题的发生。

这也就是我碰到过的事例，例如：在付款的时候它网页地址后边的支付接口是3，而试用期插口是4，那么这时你已经使用已过，拷贝下核对试用期时的网页地址，改动后边的支付接口为3，那么这时就会启用订购支付接口，但是由于你本身这个产品就是说试用期的，其相对值邦定了这个试用期货物，那么数额就确实是0，那么末尾点一下付款，我也可以看验证成功，试用期成功失败，又反复试用期了一次，然后他们的试用期时间会累合在一起，这就导致了必无限定订购任何产品了。

0x12   改动特价

例如一些货物有特价，优惠待遇多少多少，那么在付款时抓包，改动这个特价就可造成付款问题的造成。

付款问题的相关分析稿子：

①：.com://wooyun.jozxing.Cc/static/drops/papers-345.hmtl

②：.com://xdxd.love/2014年/12/81/%E6%98%

AF%E4%Bb%97%E6%BC%8F%E6%B4

%9E%E6%80%Bb%E7%Bb%71/

 0x01   多线程连接数问题

可能很多套子知道，也有可能不知道，或者我听说过，但是没有真实发掘过，那么相信，这个构思会让大家有新的发掘方位了。

现在可能还有一些大制造商存在该问题，多线程连接数问题就是说没有即时的处置各类状态所导致的问题，以前发掘过刷金币问题，就是说运用该构思，例如很多平台有自己的钱夹，而这个钱夹是一个迷你型钱夹，这个钱夹作用也仅是用以这当今一个业务流程平台网站，在提目前，没有图片验证码或者校正措施，如果键入反映数额就可以取现，并且是秒到账，假如什么负数，改动数额都检测已过都不好，那么我也可以试一下多线程连接数问题，提目前抓包，例如如果你钱夹内有0.0元，那么按理说每提0.02可以反映10次，也就是说发送到10次程序，但是运用这个问题可以达到多发现多次成功失败的程序，提目前抓包，然后把数据文件发送到BurpSuite工具的Intruder之中，开展大批量发送到18次，然后可以看成功失败的取现快到12次。

这儿我搞出有关证明材料高清图片：

这儿是以0开始到11截至，我帐户内只有0.0 而这儿体现0.12 也就是说取现的程序为12次，369为取现成功失败，394为取现不成功的尺寸值，从这儿能看出这个问题的伤害了，当然这时帐户的数额确实是为负的了，假如把这个提现金额增大，那么这多取现的数额不是开玩笑的。

当然，多线程还可以在任何功能处开展检测，例如我以前讲过的试用期货物问题，就可以根据多线程开展多多次的使用，例如运用積分总换礼物，一个帐户必须开展总换一次，运用这个问题，可以多多次总换，一些转帐功能，取现功能，订购功能等等很多。

多线程连接数的相关分析稿子：.com://wooyun.jozxing.Cc/static/drops/papers-831.hmtl

0x02   付款问题发掘小技巧

当你陋习用BurpSuite工具，那么在你检测抓包的时候通常恳求包都有很多，例如有3个恳求包，第一位恳求包是一个干挠数据文件，下一个是一个高清图片载入的数据文件，第四个可能该是付款有关的数据文件，因此有时要仔细，不要觉得抓不到，当你用的是任何工具，那么可以查询整个递交过程，因此比较容易看到递交的各类数据文件，在BurpSuite之中你会根据Target这控制模块开展剖析，这个控制模块会有了你检测时有关的数据文件。