在完成关键业务操作时，要求用户输入图形验证码是防范自动化攻击的一种措施。为安全起见，即使针对同一用户，在重新输入信息时也应该更新图形验证码。iFlow 业务安全加固平台可以加强这方面的处理。
某网站系统在登录时要求用户输入图形验证码。如果账号信息错误并得到系统提示后，用户重新输入账号信息时，仍可使用原来的图形验证码。我们看看如何利用 iFlow 使得图形验证码每次都得到更新。
一、原始网站
1.1 正常用户访问
用户在登录时输入了正确的图形验证码字符，如果提交的账号信息有误，系统提示登录错误。
用户仍使用原来的图形验证码字符，提交了正确的账号信息后，系统提示登录成功。
HTTP 交互流程如下：
1.2 攻击者访问
用户登录失败，网站没有主动更新图形验证码，而是一段时间内仍接受这个验证码。这个特性具有用户友好性，但增加了安全风险。
这样，攻击者即使没有使用图形验证码识别工具，也可以在人工识别出验证码后，在验证码过期时间之内，使用工具进行多次的撞库请求，并记录下成功登录的账号密码组合。
HTTP 交互流程如下：
二、iFlow虚拟补丁后的网站
我们在 Web 服务器前部署 iFlow 业务安全加固平台，它有能力拦截、计算和修改双向 HTTP 报文并具备存储能力，成为 Web 应用的虚拟补丁。在本例中，iFlow 记录所有出现过的验证码，不允许用户重复使用这些验证码。
2.1 正常用户访问
iFlow 不允许使用重复的验证码。正常用户登录失败后，需要刷新页面或刷新验证码再进行登录。用户如果使用相同的验证码，iFlow 会自动刷新页面并产生新的验证码，用户需要输入新的验证码进行登录。
正常用户的 HTTP 交互流程如下：
2.2 攻击者访问
如前所示，攻击者首次人工识别出验证码后，用攻击工具连续发出相同验证码的不同账号/密码组合去尝试登录。iFlow 拦截这些请求，发现验证码已使用过，则返回 302 重定向响应。鉴别过程并未在 Web 服务器上进行，攻击者得不到鉴别结果。
攻击者的 HTTP 协议交互过程如下：
2.3 代码
iFlow 内置的 W2 语言是一种专门用于实现 Web 应用安全加固的类编程语言。它介于配置和通用语言之间，具备编程的基本要素和针对 HTTP 协议的特有扩展，能为业务系统编写涉及复杂判断和动态修改的逻辑。
考虑到安全产品的使用者通常为非程序员，他们习惯面对配置文件而非一段代码。因此，W2 语言虽包含语言要素，仍以规则文件方式呈现，并采用可以体现层次结构和方便词法校验的 JSON 格式。
用 W2 语言实现上述虚拟补丁的代码如下：
{
"if": [
"streq(REQUEST_FILENAME, '/shopx/index.php')",
"streq(@ARGS.s, '/index/user/login.html')"
],
"then": {
"if": "contain(SESSION.used_vcode, @ARGS.verify)",
"then": {
"verdict": {
"action": "redirect",
"param": "/shopx/index.php?s=/index/user/logininfo.html",
"log": "user ${SESSION.user} reuse verify code."
}
},
"else": "SESSION.used_vcode@600 = SESSION.used_vcode .. ',' .. @ARGS.verify"
}
}示例代码只有一条规则，它使用存储变量 used_vcode 记录所有已使用的验证码。当有登录请求时，规则判断验证码请求参数 verify 是否在本会话 (SESSION) 的存储变量 used_vcode 中存在：
1) 如果存在：表明此请求重用了验证码，直接返回重定向到登录页面的响应。
2) 如果不存在：表明此请求使用新的验证码，将验证码加入到本会话 (SESSION) 的存储变量 used_vcode 中，继续进行实际的登录鉴别过程。
注意：上述会话中的
used_vcode是保存在服务器端的 iFlow 存储中的，攻击者在浏览器端是看不到数据更无法进行修改的。
三、总结
iFlow 使用一条规则就可以在不改动后端程序的情形下，避免用户使用重复的验证码。
需要说明的是，文中的解决方案仅是一个示例，其一定程度上影响了人机交互的流畅性。而 iFlow 是一种灵活的类编程语言，使用它应该能写出更完善的处理流程。（张戈 | 天存信息）
