WEB安全新玩法 [9] 重置密码之验证流程防绕过

通常来讲，业务流程中出现多个操做环节时，是须要顺序完成的。程序设计者每每按照正经常使用户的操做顺序实现功能，而忽略了攻击者可以绕过中途环节，直接在后续环节上进行非法操做。iFlow 业务安全加固平台可以在不修改网站程序的状况下，强制流程的顺序执行。

---

某网站系统在用户重置密码时，需进行算术题人机识别验证，再进入邮箱验证码验证环节，经过后才能真正地重置密码。因为程序设计不当，攻击者能够输入任意受害者帐号，并正常完成算术题验证后，直接绕过邮箱验证码验证过程，进入到重置受害者密码的环节。咱们接下来会看到如何利用 iFlow 来防范这类流程绕过。

1、原始网站

1.1 正经常使用户访问

用户进入登陆页面，点击找回密码连接。

在第一步确认帐号页面中输入用户名和算术题验证码。

正确提交答案后，网站向用户的注册邮箱发送验证码。用户进入第二步进行安全验证的页面，用户将邮件中的验证码在页面中输入。

邮件验证码正确，则用户可在第三步设置新密码中重置密码。

HTTP 交互流程以下：

sequenceDiagram participant 正经常使用户 participant 浏览器 participant Web服务器 participant 邮件系统 正经常使用户->>浏览器: 点击找回密码连接 浏览器->>Web服务器: GET /one/getpassword.php Web服务器->>正经常使用户: 显示：第一步页面 正经常使用户->>浏览器: 填写用户名和算术题验证码 浏览器->>Web服务器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服务器->>邮件系统: 发送验证码到邮箱 Web服务器->>正经常使用户: 显示：第二步页面 正经常使用户->>邮件系统: 以test01收取验证码 正经常使用户->>浏览器: 填写邮箱验证码 浏览器->>Web服务器: POST /one/getpassword.php<br/>action=step2,yzm=338238 Note over Web服务器: 验证邮箱验证码正确 Web服务器->>正经常使用户: 显示：第三步页面 正经常使用户->>浏览器: 填写新的密码 浏览器->>Web服务器: POST /one/getpassword.php<br/>action=step3，password=123456 Web服务器->>正经常使用户: 显示：设置新密码成功

1.2 攻击者访问

攻击者使用 Burpsuite 工具做为浏览器和 Web 服务器之间的代理，Burpsuite 能够拦截报文并修改其中内容后再发出。

攻击者在第一步确认帐号页面中填写受害者的帐号和正确的算术题验证码并点击下一步。

而后，点击浏览器的回退按钮回到上述页面，打开 Burpsuite 的拦截开关，从新填写信息，并点击下一步。攻击者能够在 Burpsuite 看到发出的第一步请求报文。

攻击者在 Burpsuite 中将请求体内容修改成第三步的报文，发往网站服务器。

攻击者在浏览器中能够看到密码重置成功的提示。

至此，攻击者在未访问受害者邮箱的状况下，顺利修改了受害者的密码。

HTTP 交互流程以下：

sequenceDiagram participant 攻击者 participant 浏览器 participant 攻击工具 participant Web服务器 participant 邮件系统 攻击者->>浏览器: 点击找回密码连接 浏览器->>Web服务器: GET /one/getpassword.php Web服务器->>攻击者: 显示：第一步页面 攻击者->>浏览器: 填写用户名和算术题验证码 浏览器->>Web服务器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服务器->>邮件系统: 发送验证码到邮箱 Web服务器->>攻击者: 显示：第二步页面 攻击者->>浏览器: 点击回退按钮 浏览器->>Web服务器: GET /one/getpassword.php Web服务器->>攻击者: 显示：第一步页面 攻击者->>浏览器: 填写用户名和算术题验证码 浏览器->>攻击工具: POST /one/getpassword.php<br/>action=step1,username=test01 rect rgb(250, 128, 128) Note over 攻击工具: 将请求修改为第三步报文 end 攻击工具->>Web服务器: POST /one/getpassword.php<br/>action=step3，password=123456 Web服务器->>攻击者: 显示：设置用户密码成功

2、iFlow虚拟补丁后的网站

咱们在 Web 服务器前部署 iFlow 业务安全加固平台，它有能力拦截、计算和修改双向 HTTP 报文并具有存储能力，成为 Web 应用的虚拟补丁。在本例中，iFlow 在进行第三步操做时，检查了第二步操做中所做的记号，确保操做没法绕过第二步直接进入第三步。

2.1 正经常使用户访问

在第二步邮箱验证码返回正确信息时，iFlow 给会话设置一个第二步完成标志。在第三步提交新密码时，iFlow 会检查第二步完成标志，若是这个标志存在，则将请求发到后端 Web 服务器进行正常处理。

正经常使用户的 HTTP 交互流程以下：

sequenceDiagram participant 正经常使用户 participant 浏览器 participant iFlow participant Web服务器 participant 邮件系统 正经常使用户->>浏览器: 点击找回密码连接 浏览器->>Web服务器: GET /one/getpassword.php Web服务器->>正经常使用户: 显示：第一步页面 正经常使用户->>浏览器: 填写用户名和算术题验证码 浏览器->>Web服务器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服务器->>邮件系统: 发送验证码到邮箱 Web服务器->>正经常使用户: 显示：第二步页面 正经常使用户->>邮件系统: 以test01收取验证码 正经常使用户->>浏览器: 填写邮箱验证码 浏览器->>Web服务器: POST /one/getpassword.php<br/>action=step2,yzm=338238 Note over Web服务器: 验证邮箱验证码正确 Web服务器->>iFlow: 返回：第二步页面 rect rgb(160, 250, 160) Note over iFlow: 设置第二步完成标志 end iFlow->>正经常使用户: 显示：第二步页面 正经常使用户->>浏览器: 填写新的密码 浏览器->>iFlow: POST /one/getpassword.php<br/>action=step3，password=123456 rect rgb(160, 250, 160) Note over iFlow: 检查第二步完成标志：存在 end iFlow->>Web服务器: 原请求报文 Web服务器->>正经常使用户: 显示：设置新密码成功

2.2 攻击者访问

如前所示，若是攻击者直接将第二步请求的报文修改成第三步请求的报文发出，iFlow 会拦截这个报文并检查第二步完成标志。因为攻击者没有实际完成第二步操做，所以也就没有第二步完成标志，iFlow 不会继续向后端 Web 服务器执行密码重置操做。

攻击者的 HTTP 协议交互过程以下：

sequenceDiagram participant 攻击者 participant 浏览器 participant 攻击工具 participant iFlow participant Web服务器 攻击者->>浏览器: 点击找回密码连接 浏览器->>Web服务器: GET /one/getpassword.php Web服务器->>攻击者: 显示：第一步页面 攻击者->>浏览器: 填写用户名和算术题验证码 浏览器->>Web服务器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服务器->>攻击者: 显示：第二步页面 攻击者->>浏览器: 点击回退按钮 浏览器->>Web服务器: GET /one/getpassword.php Web服务器->>攻击者: 显示：第一步页面 攻击者->>浏览器: 填写用户名和算术题验证码 浏览器->>攻击工具: POST /one/getpassword.php<br/>action=step1,username=test01 rect rgb(250, 128, 128) Note over 攻击工具: 修改为第三步请求 end 攻击工具->>iFlow: POST /one/getpassword.php<br/>action=step3，password=123456 rect rgb(160, 250, 160) Note over iFlow: 第二步完成标志：不存在 end iFlow->>攻击者: 显示：访问被拒绝

2.3 代码

iFlow 内置的 W2 语言是一种专门用于实现 Web 应用安全加固的类编程语言。它介于配置和通用语言之间，具有编程的基本要素和针对 HTTP 协议的特有扩展，能为业务系统编写涉及复杂判断和动态修改的逻辑。

考虑到安全产品的使用者一般为非程序员，他们习惯面对配置文件而非一段代码。所以，W2 语言虽包含语言要素，仍以规则文件方式呈现，并采用能够体现层次结构和方便词法校验的 JSON 格式。

用 W2 语言实现上述虚拟补丁的代码以下：

[
	{
		"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 存储中的，攻击者在浏览器端是看不到数据更没法进行修改的。

3、总结

iFlow 使用两条规则在不修改服务器端代码的前提下，保证了顺序操做中的关键环节不被绕过。

此外，咱们注意到，关键环节的完成判断是以响应内容做为依据而非以发起请求做为依据的，这样能够避免攻击者随手发出一个不成功的操做来欺骗 iFlow。固然，这样作的前提是 iFlow 具有强大的响应报文识别能力。（张戈 | 天存信息）