WEB安全新玩法 [8] 阻止订单重复提交
交易订单的重复提交虽然通常不会直接影响现金流和商品流,但依然会给网站运营方带来损害,如消耗系统资源、影响正常用户订单生成、制造恶意用户发起纠纷的机会等。倘若订单对象是虚拟商品,也有可能造成实际损失。订单重复提交的检查工作本应该由网站自身实现,而 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 还能构建出更复杂的防护策略。(张戈 | 天存信息)