通过质询/响应来保护会话的每个请求？

Question

我们需要设计一个安全的网络应用程序。我想提出一个会话处理机制，它对每个请求都进行质询-响应，而不仅仅是在使用CRAM 方法登录时。

原因是为了加强 Web 应用程序以防止会话劫持（例如，CSRF）和重放或中间人攻击。

在某些地方建议使用nonce，但在我们的网络应用中这似乎不切实际，因为异步请求可以继续，或者用户可以打开新窗口、点击返回按钮等。

想法：客户端和服务器有一个共享的秘密（先前建立的用户密码），每个后续请求都会根据该秘密再次进行质询/响应，例如“响应 = 哈希（挑战 + 哈希密码）”。仅当对质询的响应匹配时，服务器才会执行请求。很像 CRAM 期间，但对每个请求都持续进行。

问题：这是一个可行的想法吗？如果是这样，它肯定已经实施，甚至是某种标准？我们如何在基于 java 或 php 的 webapp 中使用它？

Answer 1

我发现OWASP cheat sheets 是此类设计决策的好资源：

• CSRF Prevention Cheat Sheet
• XSS Prevention Cheat Sheet

您的方案听起来类似于HTTP digest authentication，但没有建立任何类型的会话后身份验证。这可能是对 HTTP Basic 的改进。这是假设两者都通过 TLS！

我不确定您的方案有多可行，或者它可能有多容易受到重放攻击或 MITM。

---

如果这是一个选项，您可以考虑使用新的<keygen> html5 标签，它可以帮助建立双向 TLS 会话。这将是最安全的选择..

Answer 2

问题实际上归结为您想要实现的目标。如果你想对抗 CSRF 攻击，除了会话密钥之外，一个秘密令牌是你的方法。但是，在每个请求中更改令牌会导致问题 - 不仅后退按钮会终止会话，而且由于一个网页通常包含大量异步和并行加载的数据（图像、css、javascript 等），因此您的方法之后将不会启用任何附加数据，因为每个附加请求都会更改所需的令牌，从而终止会话。

您可以通过 BASE64 和其他技巧将所有资源嵌入到页面中来解决此问题，但这会严重阻碍您的可能性，并且可能与某些浏览器存在兼容性问题。

因此，最终，您的方法不会增加太多安全性，但很可能会给您的客户带来一整套潜在问题。我会在 URL 中的每个会话中使用一个秘密令牌来对抗 CSRF，并专注于保护其他攻击，例如 XSS 和用户友好的安全措施，例如使用智能手机或类似的东西进行双因素身份验证。毕竟，用户是当今排名第一的攻击媒介。

---

更新 (2012-06-14)

令牌不会对抗 XSS 攻击，但会防御基本的 CSRF 攻击（例如，通过在图像中植入虚假的 url 调用）。实际上，我今天在工作中遇到了一种情况，我需要确保针对用户修改和worked up some code 的获取请求。该代码还可用于保护静态会话超时form- 和link-tokens（解决您的问题）。

这个想法是有一个服务器机密，用于在数据上生成散列/AuthToken 以确保安全。如果流氓 javascript 会尝试更改任何给定数据，则 AuthToken 将不匹配。在我的具体问题中，我有一台服务器对用户进行身份验证，并且必须将他的信息发送给第三方（用户名、邮件地址、姓名等）。任何用户在身份验证后都可以轻松更改此 GET-Request，因此我必须对 GET-Request-Parameters 进行身份验证。通过重新运行 AuthenticationToken-Process，第三​​方可以比较生成的 AuthToken，从而验证传入的数据。如果没有共享秘密，就（几乎）不可能伪造数据。

关于您的问题：在 GET 和 POST 请求上使用静态令牌（或像我的项目一样的动态令牌）将保护您免受简单的 CSRF 攻击，例如论坛中的链接，用户必须单击才能受到攻击。由于链接永远不会包含正确的令牌，因此您的网页是安全的。但是，如果攻击者设法通过 XSS 将 javascript 加载到网页中，那么您就完蛋了，世界上没有任何技术可以帮助对付它，因为 javascript 可以扫描页面的整个 DOM 树以找到捕获任何令牌不管怎样。

所以，归根结底是这样的：

• 在 GET 和 POST 请求中使用令牌来对抗 CSRF
• 保护您的页面免受 XSS 注入