我们需要设计一个安全的Web应用程序。我想提出一个会话处理机制，它不仅在使用CRAM方法登录时对每个请求进行质询 - 响应。
原因是强化Web应用程序以防止会话劫持（例如通过CSRF）和重放或中间人攻击。
在某些地方建议使用nonce，但在我们的网络应用中似乎不切实际，因为异步请求可以继续，或者用户可以打开新窗口，点击后退按钮等。
创意：客户端和服务器具有共享密钥（先前建立的用户密码），每个后续请求再次基于该秘密进行质询/响应，例如'response = hash（challenge + hashedPassword）'。仅当对质询的响应匹配时，服务器才执行请求。与CRAM期间非常相似，但每次请求都在进行中。
问题：这是一个可行的想法吗？如果是这样，它肯定已经实施或甚至是一些标准？我们如何在基于java或php的webapp中使用它？
答案 0 :(得分：2)
问题实际上归结为你想要实现的目标。如果你想对抗CSRF攻击，除了会话密钥之外还有一个秘密令牌是你的方法。但是，在每个请求中更改令牌都会导致问题 - 不仅后退按钮会终止会话，而且因为一个网页通常包含大量异步和并行加载的数据（图像，css，javascript等），所以之后不会启用任何其他数据，因为每个附加请求都会更改所需的令牌，从而终止会话。
您可以通过BASE64和其他技巧将所有资源嵌入到页面中来解决这个问题，但这会严重影响您的可能性，并且可能会与某些浏览器存在兼容性问题。
因此，最终，您的方法不会增加太多安全性，但很可能会为您的客户带来一系列潜在问题。我会坚持在URL中每个会话使用一个秘密令牌来对抗CSRF，并集中精力防范其他攻击，如XSS和用户友好的安全措施，如智能手机或类似的双因素身份验证。毕竟，用户现在是＃1攻击向量。
更新（2012-06-14）
该令牌不会对抗XSS攻击，但它可以防御基本的CSRF攻击（例如，通过在图像中植入伪造的URL呼叫）。我今天的工作情况确实存在，我需要确保一个针对用户修改的get-request和worked up some code。该代码也可用于保护静态，会话超时form - 和link - 令牌（对您的问题）。
这个想法是拥有一个server-secret，用于生成一个hash / AuthToken over data来保护。如果流氓javascript会尝试更改任何给定数据，则AuthToken将不匹配。在我的具体问题中，我有一个服务器验证用户，并且必须将他的信息发送给第三方（用户名，mailaddress，名称等）。验证后，任何用户都可以轻松更改此GET-Request，因此我必须验证GET-Request-Parameters。通过重新运行AuthenticationToken-Process，第三方可以比较生成的AuthTokens，从而验证传入的数据。如果没有共享秘密，伪造数据（接近）是不可能的。
关于你的问题：在GET和POST请求（或像我的项目这样的动态请求）上拥有静态令牌将保护你免受简单的CSRF攻击，例如：论坛中的链接，用户必须点击才能受到攻击。由于链接永远不会包含正确的令牌，因此您的网页是安全的。但是，如果攻击者设法通过XSS将javascript加载到网页中，那么你就搞砸了，世界上没有任何技术可以帮助它，因为javascript可以扫描页面的整个DOM树来查找任何令牌的捕获任何。
所以，归结为：
答案 1 :(得分：2)
我发现OWASP cheat sheets是进行此类设计决策的好资源：
您的方案听起来与HTTP digest authentication类似，但没有建立任何类型的会话后验证。这可能是对HTTP Basic的改进。这是假设两者都超过了TLS！
我不确定您的方案可能有多可行，也不确定它可能是多么容易受到重播攻击或MITM攻击。
如果是一个选项，您可以考虑新的<keygen> html5标记，它可以帮助建立双向TLS会话。这将是最安全的选择..