WEB安全新玩法 [8] 阻止订单重复提交
交易订单的重复提交虽然通常不会直接影响现金流和商品流，但依然会给网站运营方带来损害，如消耗系统资源、影响正常用户订单生成、制造恶意用户发起纠纷的机会等。倘若订单对象是虚拟商品，也有可能造成实际损失。订单重复提交的检查工作本应该由网站自身实现，而 iFlow 业务安全加固平台则可以为未实现这项功能的网站提供防护。
以某开源购物网站为例，攻击者能够轻松实现订单的重复提交。我们看看如何在不修改网站源代码的前提下，使用 iFlow 通过透明加入一次性令牌来阻止订单的重复提交攻击。
一、不检查订单重复提交的原始网站
原始网站系统没有检查订单的重复提交，攻击者可以简单地重复提交订单。
1.1 正常用户访问
已登录用户在选择购买一件商品后，进入到确认订单页面：
![WEB安全新玩法 [8] 阻止订单重复提交_第1张图片](http://img.e-com-net.com/image/info8/683b8d9041d049f1821f8a4e40387a48.jpg)
用户点击提交订单按钮后，网站回复订单已生成：
![WEB安全新玩法 [8] 阻止订单重复提交_第2张图片](http://img.e-com-net.com/image/info8/330380cb52d94ece86cc7a4282df748d.jpg)
可以在我的订单列表中看到刚才的订单：
![WEB安全新玩法 [8] 阻止订单重复提交_第3张图片](http://img.e-com-net.com/image/info8/01a90efd5bd7472998822369d1b82f26.jpg)
订单生成的交互过程反映在 HTTP 协议层面如下：
1.2 攻击者访问
攻击者使用 Burpsuite 工具作为浏览器和 Web 服务器之间的代理。
攻击者象正常用户一样选择商品和确认提交后，能够在 Burpsuite 中的 HTTP history 中找到这个提交订单信息的请求。攻击者右键点击 Send to Repeater 后进入 Repeater 标签页。
![WEB安全新玩法 [8] 阻止订单重复提交_第4张图片](http://img.e-com-net.com/image/info8/33ff5e84626547b89501db5af79540d3.jpg)
攻击者通过多次点击 Send 按钮来重复发出请求报文从而重复产生订单，并可以在我的订单中看到多个重复生成的订单，如下图所示：
![WEB安全新玩法 [8] 阻止订单重复提交_第5张图片](http://img.e-com-net.com/image/info8/efa19586c2e24421b0707f9ebbd0f003.jpg)
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 还能构建出更复杂的防护策略。