大部分具有账号系统的应用都会提供重置用户登录密码的功能，常见方式之一是：用户输入自己的邮箱地址或手机号，应用向这个邮箱或手机号发送验证码，用户将收到的验证码输入应用中即可完成密码重置。这一过程容易因设计不周全而被恶意利用。**iFlow 业务安全加固平台**可以为设计不当的应用打上动态虚拟补丁，使之防御可能的恶意利用。 ----- 以某网站为例，其邮箱密码重置功能就存在缺陷：获取验证码的邮箱和重置密码的邮箱可以不一致。恶意操作能够给任意邮箱所代表的用户设置新的登录密码，从而冒充受害者登录。当然，我们也会介绍如何在不修改网站源代码的前提下，使用 **iFlow** 实现业务逻辑缺陷的修补。 # 一、原始网站 ## 1.1 正常用户访问 在密码重置页面，正常用户「alice」在**手机／邮箱**中输入自己的邮箱地址，如 *alice@mail.com*，点击**获取验证码**按钮。  网站为避免邮件发送功能被滥用，弹出图形码进行验证。用户正确填写字符并**确认**后，网站系统后台发送邮件验证码到用户「alice」的邮件地址 *alice@mail.com* 中。  用户进入到邮件系统中收取寄给 *alice@mail.com* 的邮件，将邮件中的**验证码**和需要重置的**登录密码**填写到表单中并提交。  网站判断用户输入的邮箱验证码是正确的，就将 *alice@mail.com* 所代表的用户的登录密码设置为新的密码，操作成功。 各个实体的交互流程如下：  ## 1.2 恶意访问 此处，网站在重置密码的业务处理上有个逻辑缺陷：并未确保发送邮箱验证码时的邮箱地址和设置新密码时的邮箱地址是一致的。 缺陷利用方法如下：在前面的步骤中，恶意访问者「mallory」使用自己的邮箱 *mallory@mail.com* 获取验证码。  在收到邮箱验证码并正确填写后，「mallory」将表单中的**手机／邮箱**内容改为 *alice@mail.com* (之前填的是 *mallory@mail.com* )，然后再填写新的登录密码并提交确认。  网站判断用户输入的邮箱验证码是正确的，就将 *alice@mail.com* 所代表的用户的登录密码设置为新的密码。如此一来，「mallory」成功重设了受害者「alice」的密码，并可以使用「alice」的身份登录网站。 各个实体的交互流程如下：  # 二、iFlow虚拟补丁后的网站 我们在 Web 服务器前部署 **iFlow 业务安全加固平台**，它有能力拦截、计算和修改双向 HTTP 报文并具备存储能力，成为 Web 应用的虚拟补丁。在本例中，iFlow 可保存发送验证码时的邮箱地址，并在之后设置密码时将其与输入的邮箱地址作对比，发现并制止篡改行为。 ## 2.1 正常用户访问 iFlow 在图形验证码通过时，将请求中的邮箱地址保存在 IP 存储中，在设置新密码时进行以下检查： 1) 该 IP 进行过发送验证码的操作； 2) 该 IP 要设置密码的邮箱地址与发送验证码时的邮箱相同。 各个实体的交互流程如下：  ## 2.2 恶意访问 如前所示，在收到邮箱验证码后，且未提交重设密码之前，「mallory」修改了邮箱地址。iFlow 会检查到这个变化，依此可判断这是一个恶意访问，于是终止此过程，不会让系统后端真正去修改受害者的登录密码。 恶意操作的 HTTP 协议交互过程如下：  ## 2.3 代码 **iFlow 内置的 W2 语言是一种专门用于实现 Web 应用安全加固的类编程语言**。它介于配置和通用语言之间，具备编程的基本要素和针对 HTTP 协议的特有扩展，能为业务系统编写涉及复杂判断和动态修改的逻辑。 考虑到安全产品的使用者通常为非程序员，他们习惯面对配置文件而非一段代码。因此，W2 语言虽包含语言要素，仍以规则文件方式呈现，并采用可以体现层次结构和方便词法校验的 JSON 格式。 用 W2 语言实现上述虚拟补丁的代码如下： ```json [ { "if": [ "streq(REQUEST_FILENAME, '/shopx/index.php')", "streq(@ARGS.s, '/index/user/forgetpwdverifysend.html')" ], "then": { "if": "REAL_IP.the_mail", "then": { "verdict": { "action": "deny", "log": "There is a user having reset password." } }, "else": { "if": "contain(RESPONSE_BODY, '\"code\":0,')", "then": { "execution": "REAL_IP.the_mail@120=@ARGS.accounts" } } } }, { "if": [ "streq(REQUEST_FILENAME, '/shopx/index.php')", "streq(@ARGS.s, '/index/user/forgetpwd.html')" ], "then": { "if": { "or": [ "!REAL_IP.the_mail", "strne(@ARGS.accounts, REAL_IP.the_mail)" ] }, "then": { "verdict": { "action": "deny", "log": "Invalid ${@ARGS.accounts} access" } }, "else": { "execution": "REAL_IP.the_mail=null" } } } ] ``` 示例代码中有两条规则，分别作用如下： **第一条规则** 当服务器返回图形验证结果时，iFlow 拦截此响应。如果在同一个访问端 IP 上已经在进行重置密码操作，则终止这次操作 (避免重复及交叉操作)；否则当验证结果为通过时，在访问者 IP (REAL_IP) 中创建存储变量 `the_mail` ，其值为用户输入邮箱地址。 **第二条规则** 当浏览器请求确认重置密码时，iFlow 拦截此请求。iFlow检查请求参数 `accounts` 与访问者 IP (REAL_IP) 中存储变量 `the_mail` 是否相等：如果相等则清除 `the_mail` ，以开放此访问者 IP 上的重置密码业务；如果不相等则阻止该用户的继续操作。 >**注意**：上述会话中的 `the_mail` 是保存在服务器端的 **iFlow** 存储中的，***者在浏览器端是看不到数据更无法进行修改的。 # 三、总结 iFlow 使用两条规则在不修改服务器端代码的前提下，透明地保证了重置密码时邮箱地址的一致性。从这个例子中我们可以看到，iFlow 适合构造前后报文相关联的复杂防护逻辑。（张戈 | 天存信息）