9.7

9.md

@@ -246,4 +246,58 @@ aws s3 mv test.txt s3://hackerone.marketing
 
 > 4.  我之前说过，又再说一遍，一个攻击面要好于站点，它也是公司所使用的的服务。要跳出思维定式。
 
-### 7\. 绕过 Gitlab 的双因素认证
\ No newline at end of file
+### 7\. 绕过 Gitlab 的双因素认证
+
+难度：中
+
+URL：无
+
+报告链接：`https://hackerone.com/reports/128085`
+
+报告日期：2016.4.3
+
+奖金：无
+
+描述：
+
+4 月 3 日，Jobert Abma（HackerOne 的联合创始人）向 Gitlab 报告称，在双因素认证开启情况下，攻击者能够登录受害者的账户，而不需知道受害者的密码。
+
+对于那些不熟悉的人，双因素认证是两个登录步骤，通常用户输入它们的用户名和面，之后站点会发送验证码，通常通过电子邮件或者 SMS，用户需要输入它来完成登录过程。
+
+这里，Jobert 注意到，在这个过程中，一旦攻击者输入了用户名和密码，会发送一个 Token 来结束登录。在提交这个 Token 时，POST 调用为：
+
+```
+POST /users/sign_in HTTP/1.1 
+Host: 159.xxx.xxx.xxx ...
+
+----------1881604860 
+Content-Disposition: form-data; name="user[otp_attempt]"
+
+212421 
+----------1881604860-
+```
+
+如果攻击者拦截了它并向调用添加了用户名，例如：
+
+```
+POST /users/sign_in HTTP/1.1 
+Host: 159.xxx.xxx.xxx ...
+
+----------1881604860 
+Content-Disposition: form-data; name="user[otp_attempt]"
+
+212421 
+----------1881604860 
+Content-Disposition: form-data; name="user[login]"
+
+john
+----------1881604860-
+```
+
+攻击者就能够登录进 John 的账户，如果`otp_attempt `对 John 可用。换句话说，在两步认证期间，如果攻击者添加了`user[login]`参数，它们就能修改被登录的账户。
+
+现在，唯一的麻烦就是攻击者需要拥有有效的 OTP Token，用于受害者。但是这就是爆破登场的时候了。如果站点管理员没有实现速率限制，Jobert 就可以对服务器执行重复调用来猜测有效的 Token。攻击成功的可能性取决于向服务器发送请求的传输时间，以及 Token 有效时间的长度，但是无论如何，这里的漏洞都很明显。
+
+> 重要结论
+
+> 双因素验证是个机巧的系统，难以正确实现。当你注意到站点使用了它时，你需要完整测试所有功能，包括 Token 的生命周期，尝试的最大次数，复用过期的 Token，猜测 Token 的可能性，以及其他。