交易订单的重复提交虽然通常不会直接影响现金流和商品流，但依然会给网站运营方带来损害，如消耗系统资源、影响正常用户订单生成、制造恶意用户发起纠纷的机会等。倘若订单对象是虚拟商品，也有可能造成实际损失。订单重复提交的检查工作本应该由网站自身实现，而 iFlow 业务安全加固平台则可以为未实现这项功能的网站提供防护。
以某开源购物网站为例，攻击者能够轻松实现订单的重复提交。我们看看如何在不修改网站源代码的前提下，使用 iFlow 通过透明加入一次性令牌来阻止订单的重复提交攻击。
一、不检查订单重复提交的原始网站
原始网站系统没有检查订单的重复提交，攻击者可以简单地重复提交订单。
1.1 正常用户访问
已登录用户在选择购买一件商品后，进入到确认订单页面：
图1用户点击提交订单按钮后，网站回复订单已生成：
图2可以在我的订单列表中看到刚才的订单：
图3订单生成的交互过程反映在 HTTP 协议层面如下：
表11.2 攻击者访问
攻击者使用 Burpsuite 工具作为浏览器和 Web 服务器之间的代理。
攻击者象正常用户一样选择商品和确认提交后，能够在 Burpsuite 中的 HTTP history 中找到这个提交订单信息的请求。攻击者右键点击 Send to Repeater 后进入 Repeater 标签页。
图4攻击者通过多次点击 Send 按钮来重复发出请求报文从而重复产生订单，并可以在我的订单中看到多个重复生成的订单，如下图所示：
图5HTTP 协议层面交互如下：
表2二、iFlow虚拟补丁后的网站
我们在 Web 服务器前部署 iFlow 业务安全加固平台，它有能力拦截、计算和修改双向 HTTP 报文并具备存储能力，成为 Web 应用的虚拟补丁。在本例中，iFlow 在加载订单支付代码时生成并加入一次性随机令牌，在提交订单时检查这个令牌的存在。
2.1 正常用户访问
用户在访问确认订单页面时，浏览器自动加载处理订单支付的 JS 代码 (payment_orders.js)。iFlow 截获这段代码的响应返回，生成一个随机令牌保存在本地存储中，并修改 JS 代码将随机令牌加入到 AJAX 发送列表中。用户在点击提交订单按钮时，JS 代码发出 AJAX 请求将随机令牌随同订单信息一起发出，iFlow 截获请求，检查参数中的令牌是否与保存的令牌一致，并清除本地存储中保存的令牌。对于一个正常用户来说，它们一定是相同的，于是 iFlow 去掉令牌参数，将仅包含订单信息的请求发往 Web 服务器处理。
正常用户的 HTTP 协议交互过程如下：
表32.2 攻击者访问
如前所示，攻击者记录下正常操作时的提交订单的请求报文，然后用工具重放这段报文。由于在第一次正常提交后，iFlow 已经清除了本地存储中保存的令牌，因此后续的重复提交被 iFlow 拒绝。
攻击者的 HTTP 协议交互过程如下：
表42.3 代码
iFlow 内置的 W2 语言是一种专门用于实现 Web 应用安全加固的类编程语言。它介于配置和通用语言之间，具备编程的基本要素和针对 HTTP 协议的特有扩展，能为业务系统编写涉及复杂判断和动态修改的逻辑。
考虑到安全产品的使用者通常为非程序员，他们习惯面对配置文件而非一段代码。因此，W2 语言虽包含语言要素，仍以规则文件方式呈现，并采用可以体现层次结构和方便词法校验的 JSON 格式。
用 W2 语言实现上述虚拟补丁的代码如下：
代码语言：txt复制[
{
"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 还能构建出更复杂的防护策略。（张戈 | 天存信息）
