交易訂單的重復提交雖然通常不會直接影響現金流和商品流，但依然會給網站運營方帶來損害，如消耗系統資源、影響正常用戶訂單生成、制造惡意用戶發起糾紛的機會等。倘若訂單對象是虛擬商品，也有可能造成實際損失。訂單重復提交的檢查工作本應該由網站自身實現，而 iFlow 業務安全加固平台則可以為未實現這項功能的網站提供防護。
以某開源購物網站為例，攻擊者能夠輕松實現訂單的重復提交。我們看看如何在不修改網站源代碼的前提下，使用 iFlow 通過透明加入一次性令牌來阻止訂單的重復提交攻擊。
一、不檢查訂單重復提交的原始網站
原始網站系統沒有檢查訂單的重復提交，攻擊者可以簡單地重復提交訂單。
1.1 正常用戶訪問
已登錄用戶在選擇購買一件商品后，進入到確認訂單頁面：
用戶點擊提交訂單按鈕后，網站回復訂單已生成：
可以在我的訂單列表中看到剛才的訂單：
訂單生成的交互過程反映在 HTTP 協議層面如下：
1.2 攻擊者訪問
攻擊者使用 Burpsuite 工具作為瀏覽器和 Web 服務器之間的代理。
攻擊者象正常用戶一樣選擇商品和確認提交后，能夠在 Burpsuite 中的 HTTP history 中找到這個提交訂單信息的請求。攻擊者右鍵點擊 Send to Repeater 后進入 Repeater 標簽頁。
攻擊者通過多次點擊 Send 按鈕來重復發出請求報文從而重復產生訂單，並可以在我的訂單中看到多個重復生成的訂單，如下圖所示：
HTTP 協議層面交互如下：
二、iFlow虛擬補丁后的網站
我們在 Web 服務器前部署 iFlow 業務安全加固平台，它有能力攔截、計算和修改雙向 HTTP 報文並具備存儲能力，成為 Web 應用的虛擬補丁。在本例中，iFlow 在加載訂單支付代碼時生成並加入一次性隨機令牌，在提交訂單時檢查這個令牌的存在。
2.1 正常用戶訪問
用戶在訪問確認訂單頁面時，瀏覽器自動加載處理訂單支付的 JS 代碼 (payment_orders.js)。iFlow 截獲這段代碼的響應返回，生成一個隨機令牌保存在本地存儲中，並修改 JS 代碼將隨機令牌加入到 AJAX 發送列表中。用戶在點擊提交訂單按鈕時，JS 代碼發出 AJAX 請求將隨機令牌隨同訂單信息一起發出，iFlow 截獲請求，檢查參數中的令牌是否與保存的令牌一致，並清除本地存儲中保存的令牌。對於一個正常用戶來說，它們一定是相同的，於是 iFlow 去掉令牌參數，將僅包含訂單信息的請求發往 Web 服務器處理。
正常用戶的 HTTP 協議交互過程如下：
2.2 攻擊者訪問
如前所示，攻擊者記錄下正常操作時的提交訂單的請求報文，然后用工具重放這段報文。由於在第一次正常提交后，iFlow 已經清除了本地存儲中保存的令牌，因此后續的重復提交被 iFlow 拒絕。
攻擊者的 HTTP 協議交互過程如下：
2.3 代碼
iFlow 內置的 W2 語言是一種專門用於實現 Web 應用安全加固的類編程語言。它介於配置和通用語言之間，具備編程的基本要素和針對 HTTP 協議的特有擴展，能為業務系統編寫涉及復雜判斷和動態修改的邏輯。
考慮到安全產品的使用者通常為非程序員，他們習慣面對配置文件而非一段代碼。因此，W2 語言雖包含語言要素，仍以規則文件方式呈現，並采用可以體現層次結構和方便詞法校驗的 JSON 格式。
用 W2 語言實現上述虛擬補丁的代碼如下：
[
{
"if": "REQUEST_FILENAME == '/js/payment_orders/payment_orders.js'",
"then": {
"execution": [
"TX.raw_token = md5(random())",
"SESSION.order_token@300 = TX.raw_token",
"TX.js_part = '\"' .. TX.raw_token .. '\"'",
{
"directive": "alterResponseBody",
"op": "string",
"target": "'leavemessage' : leavemessage,",
"substitute": "'leavemessage' : leavemessage, 'order_token' : ${TX.js_part},"
}
]
}
},
{
"if": [
"REQUEST_METHOD == 'POST'",
"REQUEST_FILENAME == '/index.php'",
"@ARGS.s == '/order/ordercreate'"
],
"then": {
"if": "SESSION.order_token",
"then": {
"if": "@ARGS.order_token != SESSION.order_token",
"then": {
"verdict": {
"action": "drop",
"log": "${@ARGS.order_token} is not equal to ${SESSION.order_token}!"
}
},
"else": [
"SESSIOIN.order_token = null",
{
"directive": "alterArgPost",
"op": "unset",
"name": "order_token"
}
]
},
"else": {
"verdict": {
"action": "drop",
"log": "${SESSION.order_token} is not exist!"
}
}
}
}
]
示例代碼中有兩條規則，分別作用如下：
第一條規則
當瀏覽器請求 payment_orders.js 時，iFlow 攔截響應報文。它首先生成一個隨機令牌 raw_token 並將其存放在會話 (SESSION) 存儲變量 order_token 中，然后修改處理用戶提交訂單的 AJAX 操作，將隨機令牌加入到 POST 的發送參數列表中。
第二條規則
當用戶執行提交訂單時，JS 發出一個 AJAX 的 POST 請求，iFlow 攔截此請求。它檢查會話 (SESSION) 存儲變量 order_token 和參數中的 order_token，如果前者不存在或者兩者不相等，即判定為非法請求。否則，將存儲變量 order_token 清除，將請求參數 order_token 消除 (以免影響后端應用)，然后發給后端 Web 服務器。
注意：上述會話中的
order_token標志是保存在服務器端的 iFlow 存儲中的，在瀏覽器端是看不到數據更無法進行偽造的。
三、總結
iFlow 使用兩條規則在不修改服務器端代碼的前提下，透明地實現了隨機令牌的一次性發放和使用，避免了簡單的重復提交。
當然，如果攻擊者完全模擬用戶正常操作，重復發起包含前后 2 次會話的攻擊行為，則本文中的規則無法阻擋這種重復提交。但顯然這種行為需要更復雜的攻擊技巧而不只依靠簡單地重放實現，何況，使用 iFlow 還能構建出更復雜的防護策略。（張戈 | 天存信息）