Web应用双向认证失效

在过去的两个月里，我测试了两个使用双向认证流程的网上银行应用。这些应用会向用户显示他们之前设置的秘密短语或图片：

在这两种情况下，我都通过演示这种向用户认证网站的方法几乎毫无安全价值而惹恼了开发人员，因此决定撰写博客分享发现，希望看看其他人是否同意我的观点，并期待有人能提出改进方案。

安全漏洞的核心问题

我认为这种方法的问题在于它很容易被代理攻击：攻击者创建网站的克隆版本，诱骗受害者访问。受害者输入用户名后，会被带到显示"秘密"信息的页面。此时，虚假网站将用户名传递给真实网站并启动登录流程。当获取到短语或图片时，攻击者会收集这些信息，填充到模板中并呈现给用户。下面的流程图展示了从初始钓鱼到窃取凭证的完整过程：

此时，用户看到自己的秘密信息，因此认为可以信任该网站，于是输入密码完成登录过程。攻击者现在获得了用户名和密码，可以选择将用户重定向回真实网站（让用户以为输入了错误密码并重新尝试登录），或者继续在虚假网站上维持攻击。

现有改进方案的局限性

在与他人讨论时，有人建议替代显示短语/图片的方法是通过短信或电话进行带外验证。这最初听起来是个不错的替代方案，但稍加思考就会发现它存在完全相同的问题：虚假网站可以启动登录流程，直到真实网站发送短信或拨打电话完成双向认证。用户仍然会收到来自真实网站的预期信息，从而认为他们正在访问的是可信站点。

另一个建议是在显示秘密详情之前要求完成完整登录，但这会失败，因为它让攻击者无需代理就能获得完整凭证。攻击者可以显示任意图片，或者将用户重定向回真实网站，让用户以为自己操作失误而重新尝试。

安全漏洞的放大效应

更糟糕的是，网站越强调这种双向认证，漏洞的严重性就越大。如果他们极力强调只有自己知道秘密信息，因此如果你看到它就必须是在访问真实网站，那么这种代理攻击就会更加有效。网站克隆不需要非常精确，使用的URL也不需要非常接近真实网址，因为一旦显示秘密信息，受害者就会立即信任该网站并忽略任何问题。

根本性挑战

我想不出有什么既如此易用又真正有效的系统，因为任何来自服务器的内容都可以以某种方式被代理。如果真实网站严格检查源IP并阻止来自同一源的多个请求，攻击者可以使用开放代理来发送请求；如果服务器检查HTTP头，攻击者只需转发受害者发出的确切请求。

我很希望能为客户提供替代解决方案，如果你有建议，请联系我。

感谢Michah和Anne的校对和图表协助。