支付漏洞一直以來就是是高風險，對企業來說危害很大，對用戶來說同樣危害也大。就比如我用他人賬戶進行消費，這也屬于支付漏洞中的越權問題。那么支付漏洞一般存在在哪些方面呢，根據名字就知道，凡是涉及購買、資金等方面的功能處就有可能存在支付問題。本文章將分類來進行講述支付漏洞當中的那些思路。

首先說下支付問題的思路

0|10x01   修改支付價格

在支付當中，購買商品一般分為三步驟：訂購、確認信息、付款。

那么這個修改價格具體是修改哪一步時的價格呢？在我看來，你可以在這三個步驟當中的隨便一個步驟進行修改價格測試，如果前面兩步有驗證機制，那么你可在最后一步付款時進行抓包嘗試修改金額，如果沒有在最后一步做好檢驗，那么問題就會存在，其修改的金額值你可以嘗試小數目或者嘗試負數。

這里我找到了相關例子：

①：https://bbs.ichunqiu.com/forum.php?mod=viewthread&tid=8236

②：https://bbs.ichunqiu.com/forum.php?mod=viewthread&tid=21478

③：http://www.anquan.us/static/bugs/wooyun-2016-0174748.html

0|20x02   修改支付狀態

這個問題我隱約的遇到過，之前在找相關資料的時候發現了一篇文章講的是修改支付狀態為已支付狀態這樣的思路，然后勾起了我的回想，這個問題是沒有對支付狀態的值跟實際訂單支付狀態進行校驗，導致點擊支付時抓包修改決定支付或未支付的參數為支付狀態的值從而達到支付成功。

這里是一個例子，雖然其文章作者測試失敗了，但我覺得思路是非常不錯的，例子：

①：https://bbs.ichunqiu.com/forum.php?mod=viewthread&tid=28151

0|30x03   修改購買數量

在支付的過程中，數量也同時決定著價格，比如：1個數量商品對應的是100，2個數據就是200，那么當你修改這個值數量值為負數時，那么其金額也會變為負數，最后就會導致支付問題的產生。

0|40x04   修改附屬值

這里是我自己想的一個詞，比如在很多購買的時候都可以利用積分或者優惠劵等等進行代替金額付款，那么就容易存在問題。在這里我把附屬值分為幾類進行講述。

①：修改優惠劵金額

優惠劵其基本都是優惠一半，一般用優惠劵進行消費一般出現在第二個步驟當中：確認購買信息，在這個步驟頁面當中，你可以選擇相關優惠劵，然后直接修改金額大于或等于商品的價格就可以，或者直接修改其為負值進行嘗試，最后進行支付，如果對這點沒有加以驗證，那么問題就會產生，直接支付成功。

②：修改優惠劵金額及業務邏輯問題

可能你看到這個標題會想到，你不是上一個講的就是這個修改優惠劵金額的問題嘛？為什么還要再講一遍這個？請繼續看！

之前遇到過這個漏洞，這個漏洞也是邏輯問題導致了成功利用，同樣在是在第二部確認購買信息當中有可選擇優惠劵進行支付，但是，當你修改其優惠劵值為任意值或負值想要支付的時候，會回顯支付失敗，或者金額有誤等一些提示，可能這時很多白帽子會很失望然后就會去其它點找問題了，但當你找到個人中心，點擊訂單詳情，如果存在這個邏輯問題，那么此時在你剛剛修改優惠劵金額后點擊下一步支付的時候，其實這時候就已經產生了訂單了，你在訂單詳情內就可以看到支付金額為0，因為你剛剛修改了優惠劵金額嘛，然后你點擊支付就可以支付成功。

當然，這里還要說下小技巧，有可能會支付失敗，但是如果你找到的這個問題是一個一般業務分站點，如果有自帶的一個錢包功能，那么你就可以利用這個只帶的錢包功能去支付這個訂單，而不要利用其它支付類型，那么就可以支付成功！

③：無限爆破使用優惠劵

有些廠商不注意優惠劵過期時間，這個時候就可以用抓包改包的方法，通過修改ID驗證信息來重復領取優惠劵

相關例子：http://wooyun.jozxing.cc/static/bugs/wooyun-2013-033166.html

                  http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0107744.html

④：修改積分金額

有些網站有積分，比如你消費多少，評論多少就可以擁有一定的積分數量，這個積分可以在你付款的時候進行折扣其訂單金額，如果這個沒有做好積分金額的校驗，那么當你在支付當中選擇用積分為賬戶減一些金額的時候，可以抓包修改其積分金額為任意數或負金額，然后可0元支付成功。

相關例子：http://www.anquan.us/static/bugs/wooyun-2015-0139556.html

                  http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0135459.html

0|50x05   修改支付接口

比如一些網站支持很多種支付，比如自家的支付工具，第三方的支付工具，然后每個支付接口值不一樣，如果邏輯設計不當，當我隨便選擇一個點擊支付時進行抓包，然后修改其支付接口為一個不存在的接口，如果沒做好不存在接口相關處理，那么此時就會支付成功。

0|60x06   多重替換支付

以前好像也看到過相關的例子，首先去產生兩個訂單，這兩個訂單商品是不一樣的，其價格不一樣，如果服務端沒有做好這相關的驗證，那么在支付的過程當中抓包，修改其訂單值為另一個訂單值，最后支付，這時就可以用訂單一的支付價格買到訂單而的商品。

0|70x07   重復支付

這個其實只是支付當中的一個別類，但是這個思路新穎，所以我就列了出來，比如一些交易市場有一類似于試用牌子或者其它，這個試用牌子可以依靠簽到獲得，而這個牌子的作用可以去試用一些商品，在你進行試用的時候會扣掉你的試用牌子，當你試用完成或者主動取消試用時，試用牌子會返回到賬戶當中，你知道，簽到得到的牌子肯定很少，且如果想試用好一點的商品那么牌子的數量就尤為重要了。

這里的問題就是如果沒有進行對訂單多重提交的校驗，那么就可導致無限制刷牌子，比如，你試用時抓包，然后你每次試用都會產生一個訂單號，然后利用剛抓到的數據包進行批量提交，你就可以看到每次提交的訂單號不一樣，然后這時你再看訂單可以看到同一個商品的無數訂單，但試用牌子數只扣了你第一個試驗時的牌子數，那么這時你申請批量退出試用，那么這么多訂單，每退一個就會退相應的牌子數量到賬戶當中，這就構成了無限制刷得問題。

0|80x08   最小額支付

在很多白帽子測試支付的漏洞時候，修改的金額往往都是0.01等或者負數，我想說這很容易錯失掉一些潛在的支付問題，我就深有體會，在挖掘支付漏洞的過程當中，就遇到過，直到第三次再一次檢測時才發現，比如一些網站有金幣或者積分什么就相當于支付可以用這些支付，那么在充值的時候，比如：10元對應的積分值為100、50對應的是5000、100對應的是10000。

這個問題如果你在充值時進行修改其支付金額為負數或者0.01等是會顯示支付失敗的，但是如果你修改其金額為1.00，那么支付就會成功，也就用1元購買到任意值得積分數量了，這是為什么呢？

其實你在測試過程當中細心點就可以很好發現的，這里最低就是1元，1元對應100積分，而你如果修改為0.01，那么對應的積分就是空值了，所以會顯示失敗，而當你修改為1元，那么1元這個支付接口是存在的，其后面積分數為其它金額的積分數，然后跳轉過去支付就會以1元購買到比它多得多的積分數量，也可以是任意積分值。

0|90x09   值為最大值支付問題

以前也是看到過相關的例子，一些網站比如你購買商品，這里有2個思路修改值，1是直接修改支付金額值為最大值，比如999999999，或者修改附屬值，如優惠卷，積分等為999999999，如果這里邏輯設計有問題，那么其支付金額會變為0。

0|100x10   越權支付

這個問題很早之前有過，現在可能很少存在這類問題，在支付當中會出現當前用戶的ID，比如：username=XXXXX，如果沒有加以驗證，其支付也是一次性支付沒有要求輸入密碼什么的機制，那么就可以修改這個用戶ID為其它用戶ID，達到用其他用戶的賬號進行支付你的商品。

0|110x11   無限制試用

一些網站的一些商品，比如云系列產品支持試用，試用時期一般為7天或者30天，一個賬戶只能試用一次，試用期間不能再試用，但如果這個試用接口會做好分配那么很容易導致問題的發生。

這也是我遇到過的例子，比如：在支付的時候它URL后面的支付接口是3，而試用接口是4，那么此時你已經使用過了，復制下確認試用時的URL，修改后面的支付接口為3，那么此時就會調用購買支付接口，但是由于你本身這個產品就是試用的，其相應值綁定了這個試用商品，那么金額就肯定是0，那么最后點擊支付，你就可以看到支付成功，試用成功，又重復試用了一次，然后他們的試用時間會累加在一起，這就導致了可無限制購買任何產品了。

0|120x12   修改優惠價

比如一些商品有優惠價，優惠多少多少，那么在支付時抓包，修改這個優惠價就可造成支付問題的產生。

支付問題的相關分析文章：

①：http://wooyun.jozxing.cc/static/drops/papers-345.html

1|0以下是不常見思路

可能很多白帽子知道，也有可能不知道，或者聽說過，但是沒有實際挖掘過，那么我相信，這個思路會讓你們有新的挖掘方向了。

現在可能還有一些大廠商存在該問題，多線程并發問題就是沒有實時的處理各種狀態所導致的問題，之前挖掘過刷錢問題，就是利用該思路，比如很多平臺有自家的錢包，而這個錢包是一個迷你錢包，這個錢包作用也僅是用于這當前一個業務平臺網站，在提現時，沒有任何驗證碼或者校驗機制，只要輸入體現金額就可以提現，并且是秒到賬，如果什么負數，修改金額都測試過了都不行，那么你就可以試試多線程并發問題，提現時抓包，比如我現在錢包內有0.1元，那么按理說每提0.01可以體現10次，也就是發送10次進程，但是利用這個問題可以達到多發現幾次成功的進程，提現時抓包，然后把數據包發送到BurpSuite工具的Intruder當中，進行批量發送18次，然后可以看到成功的提現到了12次。

這里我貼出相關證明圖片：

這里是從0開始到11截止，我賬戶內只有0.1 而這里體現了0.12 也就是提現的進程為12次，369為提現成功，349為提現失敗的長度值，從這里就可以看出這個問題的危害了，當然此時賬戶的金額肯定是為負的了，如果把這個提現金額變大，那么這多提現的金額可不是鬧著玩的。

當然，多線程也可以在其它功能處進行測試，比如我之前講到的試用商品問題，就可以通過多線程進行多幾次的使用，比如利用積分總換禮品，一個賬戶只能進行總換一次，利用這個問題，可以多幾次總換，一些轉賬功能，提現功能，購買功能等等很多。

多線程并發的相關分析文章：http://wooyun.jozxing.cc/static/drops/papers-831.html

1|20x02   支付問題挖掘技巧

如果你習慣用BurpSuite工具，那么在你測試抓包的時候通常請求包都有很多，比如有3個請求包，第一個請求包是一個干擾數據包，第二個是一個圖片加載的數據包，第三個可能才是支付相關的數據包，所以有時候要細心，不要認為抓不到，如果你用的是其它工具，那么可以查看整個提交過程，所以很容易看到提交的各種數據包，在BurpSuite當中你可以通過Target這模塊進行分析，這個模塊會有你測試時相關的數據包。

以下是不常見思路

 0x01   多線程并發問題

可能很多白帽子知道，也有可能不知道，或者聽說過，但是沒有實際挖掘過，那么我相信，這個思路會讓你們有新的挖掘方向了。

現在可能還有一些大廠商存在該問題，多線程并發問題就是沒有實時的處理各種狀態所導致的問題，之前挖掘過刷錢問題，就是利用該思路，比如很多平臺有自家的錢包，而這個錢包是一個迷你錢包，這個錢包作用也僅是用于這當前一個業務平臺網站，在提現時，沒有任何驗證碼或者校驗機制，只要輸入體現金額就可以提現，并且是秒到賬，如果什么負數，修改金額都測試過了都不行，那么你就可以試試多線程并發問題，提現時抓包，比如我現在錢包內有0.1元，那么按理說每提0.01可以體現10次，也就是發送10次進程，但是利用這個問題可以達到多發現幾次成功的進程，提現時抓包，然后把數據包發送到BurpSuite工具的Intruder當中，進行批量發送18次，然后可以看到成功的提現到了12次。

這里我貼出相關證明圖片：

這里是從0開始到11截止，我賬戶內只有0.1 而這里體現了0.12 也就是提現的進程為12次，369為提現成功，349為提現失敗的長度值，從這里就可以看出這個問題的危害了，當然此時賬戶的金額肯定是為負的了，如果把這個提現金額變大，那么這多提現的金額可不是鬧著玩的。

當然，多線程也可以在其它功能處進行測試，比如我之前講到的試用商品問題，就可以通過多線程進行多幾次的使用，比如利用積分總換禮品，一個賬戶只能進行總換一次，利用這個問題，可以多幾次總換，一些轉賬功能，提現功能，購買功能等等很多。

多線程并發的相關分析文章：http://wooyun.jozxing.cc/static/drops/papers-831.html

0x02   支付問題挖掘技巧

如果你習慣用BurpSuite工具，那么在你測試抓包的時候通常請求包都有很多，比如有3個請求包，第一個請求包是一個干擾數據包，第二個是一個圖片加載的數據包，第三個可能才是支付相關的數據包，所以有時候要細心，不要認為抓不到，如果你用的是其它工具，那么可以查看整個提交過程，所以很容易看到提交的各種數據包，在BurpSuite當中你可以通過Target這模塊進行分析，這個模塊會有你測試時相關的數據包。