一般来说，业务流程中出现多个操作环节时，是需要顺序完成的。程序设计者往往按照正常用户的操作顺序实现功能，而忽略了攻击者能够绕过中途环节，直接在后续环节上进行非法操作。iFlow 业务安全加固平台能够在不修改网站程序的情况下，强制流程的顺序执行。
某网站系统在用户重置密码时，需进行算术题人机识别验证，再进入邮箱验证码验证环节，通过后才能真正地重置密码。由于程序设计不当，攻击者可以输入任意受害者账号，并正常完成算术题验证后，直接绕过邮箱验证码验证过程，进入到重置受害者密码的环节。我们接下来会看到如何利用 iFlow 来防范这类流程绕过。
一、原始网站
1.1 正常用户访问
用户进入登录页面，点击找回密码链接。
图1在第一步确认账号页面中输入用户名和算术题验证码。
图2正确提交答案后，网站向用户的注册邮箱发送验证码。用户进入第二步进行安全验证的页面，用户将邮件中的验证码在页面中输入。
图3邮件验证码正确，则用户可在第三步设置新密码中重置密码。
图4HTTP 交互流程如下：
表11.2 攻击者访问
攻击者使用 Burpsuite 工具作为浏览器和 Web 服务器之间的代理，Burpsuite 可以拦截报文并修改其中内容后再发出。
攻击者在第一步确认账号页面中填写受害者的账号和正确的算术题验证码并点击下一步。
图5然后，点击浏览器的回退按钮回到上述页面，打开 Burpsuite 的拦截开关，重新填写信息，并点击下一步。攻击者可以在 Burpsuite 看到发出的第一步请求报文。
图6攻击者在 Burpsuite 中将请求体内容修改为第三步的报文，发往网站服务器。
图7攻击者在浏览器中可以看到密码重置成功的提示。
图8至此，攻击者在未访问受害者邮箱的情况下，顺利修改了受害者的密码。
HTTP 交互流程如下：
表2二、iFlow虚拟补丁后的网站
我们在 Web 服务器前部署 iFlow 业务安全加固平台，它有能力拦截、计算和修改双向 HTTP 报文并具备存储能力，成为 Web 应用的虚拟补丁。在本例中，iFlow 在进行第三步操作时，检查了第二步操作中所作的记号，确保操作无法绕过第二步直接进入第三步。
2.1 正常用户访问
在第二步邮箱验证码返回正确信息时，iFlow 给会话设置一个第二步完成标志。在第三步提交新密码时，iFlow 会检查第二步完成标志，如果这个标志存在，则将请求发到后端 Web 服务器进行正常处理。
正常用户的 HTTP 交互流程如下：
表32.2 攻击者访问
如前所示，如果攻击者直接将第二步请求的报文修改为第三步请求的报文发出，iFlow 会拦截这个报文并检查第二步完成标志。由于攻击者没有实际完成第二步操作，因此也就没有第二步完成标志，iFlow 不会继续向后端 Web 服务器执行密码重置操作。
攻击者的 HTTP 协议交互过程如下：
表42.3 代码
iFlow 内置的 W2 语言是一种专门用于实现 Web 应用安全加固的类编程语言。它介于配置和通用语言之间，具备编程的基本要素和针对 HTTP 协议的特有扩展，能为业务系统编写涉及复杂判断和动态修改的逻辑。
考虑到安全产品的使用者通常为非程序员，他们习惯面对配置文件而非一段代码。因此，W2 语言虽包含语言要素，仍以规则文件方式呈现，并采用可以体现层次结构和方便词法校验的 JSON 格式。
用 W2 语言实现上述虚拟补丁的代码如下：
代码语言：txt复制[
{
"if": [
"REQUEST_FILENAME == '/ajax/yzm_check_ajax.php'",
{
"variable": "RESPONSE_BODY",
"operator": "contain",
"pattern": "window.document.userreg.yzm_mobile2.value='yes'"
}
],
"then": "SESSION.step2_ok@300 = true"
},
{
"if": [
"REQUEST_METHOD == 'POST'",
"REQUEST_FILENAME == '/one/getpassword.php'",
"@ARGS.action == 'step3'"
],
"then": {
"if": "SESSION.step2_ok",
"then": "SESSION.step2_ok=null",
"else": {
"execution": "SESSION.step2_ok=null",
"verdict": {
"action": "deny",
"log": "invalid access step3!"
}
}
}
}
]示例代码中有两条规则，分别作用如下：
第一条规则
当服务器在第二步操作返回邮箱验证码成功时，iFlow 拦截此响应。并且，iFlow 将创建一个会话 (SESSION) 的存储变量 step2_ok 为 true。
第二条规则
当浏览器请求第三步操作即确认重置密码时，iFlow 拦截此请求。iFlow 将检查会话 (SESSION) 的存储变量 step2_ok 是否存在：如果存在则放行，不存在则拒绝访问。不管哪种情形，存储变量 step2_ok 都会被清除，以防止第三步被重复单独访问。
注意：上述会话中的
step2_ok是保存在服务器端的 iFlow 存储中的，攻击者在浏览器端是看不到数据更无法进行修改的。
三、总结
iFlow 使用两条规则在不修改服务器端代码的前提下，保证了顺序操作中的关键环节不被绕过。
此外，我们注意到，关键环节的完成判断是以响应内容作为依据而非以发起请求作为依据的，这样可以避免攻击者随手发出一个不成功的操作来欺骗 iFlow。当然，这样做的前提是 iFlow 具备强大的响应报文识别能力。（张戈 | 天存信息）
