涉及錢時，必須考慮防刷、限量和防重
任何涉及錢的代碼必須要考慮防刷、限量和防重，要做好安全兜底。涉及錢的代碼，主要有以下三類。
第一，代碼本身涉及有償使用的三方服務。如果因為代碼本身缺少授權、用量控制而被利用導致大量調用，勢必會消耗大量的錢，給公司造成損失。有些三方服務可能采用后付款方式的結算，出現問題后如果沒及時發現，下個月結算時就會收到一筆數額巨大的賬單。
第二，代碼涉及虛擬資產的發放，比如積分、優惠券等。雖然說虛擬資產不直接對應貨幣，但一般可以在平臺兌換具有真實價值的資產。比如，優惠券可以在下單時使用，積分可以兌換積分商城的商品。所以從某種意義上說，虛擬資產就是具有一定價值的錢，但因為不直接涉及錢和外部資金通道，所以容易產生隨意性發放而導致漏洞。
第三，代碼涉及真實錢的進出。比如，對用戶扣款，如果出現非正常的多次重復扣款，小則用戶投訴、用戶流失，大則被相關管理機構要求停業整改，影響業務。又比如，給用戶發放返現的付款功能，如果出現漏洞造成重復付款，涉及 B 端的可能還好，但涉及 C 端用戶的重復付款可能永遠無法追回。
前段時間拼多多一夜之間被刷了大量 100 元無門檻優惠券的事情，就是限量和防刷出了問題。
今天，我們就通過三個例子，和你說明如何在代碼層面做好安全兜底。
開放平臺資源的使用需要考慮防刷
我以真實遇到的短信服務被刷案例，和你說說防刷。
有次短信賬單月結時發現，之前每個月是幾千元的短信費用，這個月突然變為了幾萬元。查數據庫記錄發現，之前是每天發送幾千條短信驗證碼，從某天開始突然變為了每天幾萬條，但注冊用戶數并沒有激增。顯然，這是短信接口被刷了。
我們知道，短信驗證碼服務屬于開放性服務，由用戶側觸發，且因為是注冊驗證碼所以不需要登錄就可以使用。如果我們的發短信接口像這樣沒有任何防刷的防護，直接調用三方短信通道，就相當于“裸奔”，很容易被短信轟炸平臺利用：
@GetMapping("wrong")
publicvoid wrong() {
sendSMSCaptcha("13600000000");
}
privatevoid sendSMSCaptcha(String mobile) {
//調用短信通道
}對于短信驗證碼這種開放接口，程序邏輯內需要有防刷邏輯。好的防刷邏輯是，對正常使用的用戶毫無影響，只有疑似異常使用的用戶才會感受到。對于短信驗證碼，有如下 4 種可行的方式來防刷。
第一種方式，只有固定的請求頭才能發送驗證碼。
也就是說，我們通過請求頭中網頁或 App 客戶端傳給服務端的一些額外參數，來判斷請求是不是 App 發起的。其實，這種方式“防君子不防小人”。
比如，判斷是否存在瀏覽器或手機型號、設備分辨率請求頭。對于那些使用爬蟲來抓取短信接口地址的程序來說，往往只能抓取到 URL，而難以分析出請求發送短信還需要的額外請求頭，可以看作第一道基本防御。
第二種方式，只有先到過注冊頁面才能發送驗證碼。
對于普通用戶來說，不管是通過 App 注冊還是 H5 頁面注冊，一定是先進入注冊頁面才能看到發送驗證碼按鈕，再點擊發送。我們可以在頁面或界面打開時請求固定的前置接口，為這個設備開啟允許發送驗證碼的窗口，之后的請求發送驗證碼才是有效請求。
這種方式可以防御直接繞開固定流程，通過接口直接調用的發送驗證碼請求，并不會干擾普通用戶。
第三種方式，控制相同手機號的發送次數和發送頻次。
除非是短信無法收到，否則用戶不太會請求了驗證碼后不完成注冊流程，再重新請求。因此，我們可以限制同一手機號每天的最大請求次數。驗證碼的到達需要時間，太短的發送間隔沒有意義，所以我們還可以控制發送的最短間隔。比如，我們可以控制相同手機號一天只能發送 10 次驗證碼，最短發送間隔 1 分鐘。
第四種方式，增加前置圖形驗證碼。
短信轟炸平臺一般會收集很多免費短信接口，一個接口只會給一個用戶發一次短信，所以控制相同手機號發送次數和間隔的方式不夠有效。這時，我們可以考慮對用戶體驗稍微有影響，但也是最有效的方式作為保底，即將彈出圖形驗證碼作為前置。
除了圖形驗證碼，我們還可以使用其他更友好的人機驗證手段（比如滑動、點擊驗證碼等），甚至是引入比較新潮的無感知驗證碼方案（比如，通過判斷用戶輸入手機號的打字節奏，來判斷是用戶還是機器），來改善用戶體驗。
此外，我們也可以考慮在監測到異常的情況下再彈出人機檢測。比如，短時間內大量相同遠端 IP 發送驗證碼的時候，才會觸發人機檢測。
總之，我們要確保，只有正常用戶經過正常的流程才能使用開放平臺資源，并且資源的用量在業務需求合理范圍內。此外，還需要考慮做好短信發送量的實時監控，遇到發送量激增要及時報警。
接下來，我們一起看看限量的問題。
虛擬資產并不能憑空產生無限使用
虛擬資產雖然是平臺方自己生產和控制，但如果生產出來可以立即使用就有立即變現的可能性。比如，因為平臺 Bug 有大量用戶領取高額優惠券，并立即下單使用。
在商家看來，這很可能只是一個用戶支付的訂單，并不會感知到用戶使用平臺方優惠券的情況；同時，因為平臺和商家是事后結算的，所以會馬上安排發貨。而發貨后基本就不可逆了，一夜之間造成了大量資金損失。
我們從代碼層面模擬一個優惠券被刷的例子。
假設有一個 CouponCenter 類負責優惠券的產生和發放。如下是錯誤做法，只要調用方需要，就可以憑空產生無限的優惠券：
@Slf4j
publicclass CouponCenter {
//用于統計發了多少優惠券
AtomicInteger totalSent = new AtomicInteger(0);
public void sendCoupon(Coupon coupon) {
if (coupon != null)
totalSent.incrementAndGet();
}
public int getTotalSentCoupon() {
return totalSent.get();
}
//沒有任何限制，來多少請求生成多少優惠券
public Coupon generateCouponWrong(long userId, BigDecimal amount) {
returnnew Coupon(userId, amount);
}
}這樣一來，使用 CouponCenter 的 generateCouponWrong 方法，想發多少優惠券就可以發多少：
@GetMapping("wrong")
public int wrong() {
CouponCenter couponCenter = new CouponCenter();
//發送10000個優惠券
IntStream.rangeClosed(1, 10000).forEach(i -> {
Coupon coupon = couponCenter.generateCouponWrong(1L, new BigDecimal("100"));
couponCenter.sendCoupon(coupon);
});
return couponCenter.getTotalSentCoupon();
}更合適的做法是，把優惠券看作一種資源，其生產不是憑空的，而是需要事先申請，理由是：
虛擬資產如果最終可以對應到真實金錢上的優惠，那么，能發多少取決于運營和財務的核算，應該是有計劃、有上限的。引言提到的無門檻優惠券，需要特別小心。有門檻優惠券的大量使用至少會帶來大量真實的消費，而使用無門檻優惠券下的訂單，可能用戶一分錢都沒有支付。
即使虛擬資產不值錢，大量不合常規的虛擬資產流入市場，也會沖垮虛擬資產的經濟體系，造成虛擬貨幣的極速貶值。有量的控制才有價值。
資產的申請需要理由，甚至需要走流程，這樣才可以追溯是什么活動需要、誰提出的申請，程序依據申請批次來發放。
接下來，我們按照這個思路改進一下程序。
首先，定義一個 CouponBatch 類，要產生優惠券必須先向運營申請優惠券批次，批次中包含了固定張數的優惠券、申請原因等信息：
//優惠券批次
@Data
publicclass CouponBatch {
privatelong id;
private AtomicInteger totalCount;
private AtomicInteger remainCount;
private BigDecimal amount;
private String reason;
}在業務需要發放優惠券的時候，先申請批次，然后再通過批次發放優惠券：
@GetMapping("right")
public int right() {
CouponCenter couponCenter = new CouponCenter();
//申請批次
CouponBatch couponBatch = couponCenter.generateCouponBatch();
IntStream.rangeClosed(1, 10000).forEach(i -> {
Coupon coupon = couponCenter.generateCouponRight(1L, couponBatch);
//發放優惠券
couponCenter.sendCoupon(coupon);
});
return couponCenter.getTotalSentCoupon();
}可以看到，generateCouponBatch 方法申請批次時，設定了這個批次包含 100 張優惠券。在通過 generateCouponRight 方法發放優惠券時，每發一次都會從批次中扣除一張優惠券，發完了就沒有了：
public Coupon generateCouponRight(long userId, CouponBatch couponBatch) {
if (couponBatch.getRemainCount().decrementAndGet() >= 0) {
returnnew Coupon(userId, couponBatch.getAmount());
} else {
log.info("優惠券批次 {} 剩余優惠券不足", couponBatch.getId());
returnnull;
}
}
public CouponBatch generateCouponBatch() {
CouponBatch couponBatch = new CouponBatch();
couponBatch.setAmount(new BigDecimal("100"));
couponBatch.setId(1L);
couponBatch.setTotalCount(new AtomicInteger(100));
couponBatch.setRemainCount(couponBatch.getTotalCount());
couponBatch.setReason("XXX活動");
return couponBatch;
}這樣改進后的程序，一個批次最多只能發放 100 張優惠券：
因為是 Demo，所以我們只是憑空 new 出來一個 Coupon。在真實的生產級代碼中，一定是根據 CouponBatch 在數據庫中插入一定量的 Coupon 記錄，每一個優惠券都有唯一的 ID，可跟蹤、可注銷。
最后，我們再看看防重。
錢的進出一定要和訂單掛鉤并且實現冪等
涉及錢的進出，需要做好以下兩點。
第一，任何資金操作都需要在平臺側生成業務屬性的訂單，可以是優惠券發放訂單，可以是返現訂單，也可以是借款訂單，一定是先有訂單再去做資金操作。同時，訂單的產生需要有業務屬性。業務屬性是指，訂單不是憑空產生的，否則就沒有控制的意義。比如，返現發放訂單必須關聯到原先的商品訂單產生；再比如，借款訂單必須關聯到同一個借款合同產生。
第二，一定要做好防重，也就是實現冪等處理，并且冪等處理必須是全鏈路的。這里的全鏈路是指，從前到后都需要有相同的業務訂單號來貫穿，實現最終的支付防重。
關于這兩點，你可以參考下面的代碼示例：
//錯誤：每次使用UUID作為訂單號
@GetMapping("wrong")
publicvoid wrong(@RequestParam("orderId") String orderId) {
PayChannel.pay(UUID.randomUUID().toString(), "123", new BigDecimal("100"));
}
//正確：使用相同的業務訂單號
@GetMapping("right")
publicvoid right(@RequestParam("orderId") String orderId) {
PayChannel.pay(orderId, "123", new BigDecimal("100"));
}
//三方支付通道
publicclass PayChannel {
publicstaticvoid pay(String orderId, String account, BigDecimal amount) {
...
}
}對于支付操作，我們一定是調用三方支付公司的接口或銀行接口進行處理的。一般而言，這些接口都會有商戶訂單號的概念，對于相同的商戶訂單號，無法進行重復的資金處理，所以三方公司的接口可以實現唯一訂單號的冪等處理。
但是，業務系統在實現資金操作時容易犯的錯是，沒有自始至終地使用一個訂單號作為商戶訂單號，透傳給三方支付接口。出現這個問題的原因是，比較大的互聯網公司一般會把支付獨立一個部門。支付部門可能會針對支付做聚合操作，內部會維護一個支付訂單號，然后使用支付訂單號和三方支付接口交互。最終雖然商品訂單是一個，但支付訂單是多個，相同的商品訂單因為產生多個支付訂單導致多次支付。
如果說，支付出現了重復扣款，我們可以給用戶進行退款操作，但給用戶付款的操作一旦出現重復付款，就很難把錢追回來了，所以更要小心。
這，就是全鏈路的意義，從一開始就需要先有業務訂單產生，然后使用相同的業務訂單號一直貫穿到最后的資金通路，才能真正避免重復資金操作。
重點回顧
今天，我從安全兜底聊起，和你分享了涉及錢的業務最需要做的三方面工作，防刷、限量和防重。
第一，使用開放的、面向用戶的平臺資源要考慮防刷，主要包括正常使用流程識別、人機識別、單人限量和全局限量等手段。
第二，虛擬資產不能憑空產生，一定是先有發放計劃、申請批次，然后通過批次來生產資產。這樣才能達到限量、有審計、能追溯的目的。
第三，真實錢的進出操作要額外小心，做好防重處理。不能憑空去操作用戶的賬戶，每次操作以真實的訂單作為依據，通過業務訂單號實現全鏈路的冪等控制。
如果程序邏輯涉及有價值的資源或是真實的錢，我們必須有敬畏之心。程序上線后，人是有休息時間的，但程序是一直運行著的，如果產生安全漏洞，就很可能在一夜之間爆發，被大量人利用導致大量的金錢損失。
除了在流程上做好防刷、限量和防重控制之外，我們還需要做好三方平臺調用量、虛擬資產使用量、交易量、交易金額等重要數據的監控報警，這樣即使出現問題也能第一時間發現。
