CSRF 保护：散列的 PHPSESSID 足够了吗？答案

【问题标题】：CSRF Protection: Hashed PHPSESSID enough?CSRF 保护：散列的 PHPSESSID 足够了吗？
【发布时间】：2017-09-03 06:22:06
【问题描述】：

只是想知道是否需要将散列的 PHPSESSID 发送到所有表单或操作脚本就足以保护 CSRF？我知道如果用户在同一个物理网络（firesheep）上，就可以获得这一点。示例：

http://site.com/deleteMessage.php?mid=22&token=MD5ed_PHPSESSID

忽略相同的网络问题 PHPSESSID：

 1) Is known only to the user doing the action
 2) Can not be guessed by an attacker crafting a malicious img or request (<img src="http://site.com/deleteMessage.php?mid=22&token=I_DONT_KNOW_IT_:( )
 3) Can not be pulled on the same site assuming no XSS vulnerabilities exist.
 4) Can easily be pulled by the legitimate user (Javascript fills the form or GET var in the link)

数字 3 让我担心，虽然我没有任何我知道的 XSS 漏洞，因为我 htmlentities($string,ENT_QUOTES)ed 一切，我不喜欢依赖假设。这是足够的 CSRF 保护还是有更好的方法？

【问题讨论】：

为了避免像 Firesheep 这样的攻击，你应该对任何你想要验证会话的东西强制使用 HTTPS。
@Lèse majesté 没错，但这与他的问题无关。也许您应该与 stackoverflow 谈谈他们对 https 的使用（或缺少）。
@Rook：这不是问题的答案（因此我发表了评论），但他确实特别提到了如果在不安全的网络上使用 Firesheep 捕获他的 CSRF 令牌的潜力。

标签： php security xss csrf

【解决方案1】：

如果攻击者知道会话 id，那么他就不必使用 CSRF 来影响受害者的会话。使用散列会话 ID 是不好的做法，但它不是漏洞。你甚至可以使用会话 id 本身，并且它在技术上不易受 CSRF 攻击。但它增加了失败的可能性，并且防止这种失败是免费的。另一个密码随机数很容易生成。

XSS 破坏了CSRF prevention cheat sheet 上的所有保护方法，除了使用 capthca。话虽如此，您应该使用 HTTP_Only cookie 标志来保护您的会话 ID 免受 XSS 攻击。

请记住，HTTP_only 标志不会阻止 XSS！，它只会使其更难被利用。攻击者经常求助于使用 XHR 读取 CSRF 令牌以“骑”在会话上，而不是劫持会话 ID。

【讨论】：

如果它不是漏洞，那你为什么考虑使用散列会话 ID 不好的做法？
@Lèse majesté 看看秋葵汤的 cmets。它可以破坏其他奇异的安全系统。此外，另一个加密随机数是免费的。
@Rook：我无法理解散列的 CSRF 如何增加失败的可能性（假设使用了加密安全的散列）。你能详细说明一下吗？如果攻击者能够捕获会话，我能想到的所有攻击场景都允许避免 CSRF 保护。
@Mikko Rantalainen 使用哈希会话 id 作为 CSRF 令牌让我觉得这是一个糟糕的设计。这些应该是自变量。我认为秋葵汤在这种情况下有更好的答案。
@Rook：声称某些东西是“糟糕的设计”，甚至没有解释一个理论问题，在我看来就像货物崇拜设计/编程。我知道使 CSRF 令牌独立于会话 ID 显然是安全的。但是，我认为完全没有理由声称使 CSRF 令牌依赖于会话 ID 是不安全的。我想指出不正确...

【解决方案2】：

不，您应该使用独立于会话 ID 的令牌。试想一下，攻击站点能够以某种方式获取受害者的会话 ID（参见 session fixation 和 session hijacking）但由于一些额外的会话保护措施而无法使用会话本身。然后仍然可以伪造真实的请求，因为令牌可以从已知的会话 ID 中派生出来。

按照大家的建议使用随机令牌。

【讨论】：

如果攻击者有会话ID，那么他就有了王国的钥匙。他不必求助于 CSRF，因为他有更好的东西。他可以加载一个页面并直接从表单中读取 CSRF 令牌，或者只是使用他的浏览器提交表单。鸡还是鸡蛋。
@Rook 不，不一定在所有情况下都是如此。想想其他会话保护措施，即使不是不可能，至少也更难直接使用该会话。
唯一的情况是将 IP 地址链接到会话 ID。但这有其自身的问题。没有其他形式的保护或其他条件、期限。
@Rook IP 地址是一个例子，客户端证书是另一个例子。并且可能存在攻击站点未知的其他条件，这可能会使直接使用会话变得更加困难。

【解决方案3】：

防止 CSRF 的最简单方法是在加载带有要保护的表单的页面时向会话添加随机哈希。将该值添加到表单中，以便当用户提交时它会随之而来。将其与另一端的会话值匹配。

每次显示表单时重新生成这个随机值。

这是可行的，因为如果用户离开并返回，移动到新表单，无论如何，表单将始终与创建的最后一个值匹配，而这又与您检查的相同。

您的建议可能会有所帮助，但在您提到的方式中仍然容易受到攻击。为什么允许任何漏洞？

【讨论】：

同一网络上的用户总是可以截取随机值以及会话。页面上的离线 XSS 将能够从表单中获取随机值并提交。我错过了什么吗？
这就是为什么每次用户加载表单时都要更改它的原因。使用 SSL(https) 可以防止窃取会话，您应该这样做。安全的规则是尽可能的硬，即使有一个防御被破坏，也不要放弃整场比赛。
在构建您的随机令牌时，如果有任何 md5() 使用（不仅如此），请在其中添加一些盐。
@Ronan Salt 不需要。由于您在哈希中使用随机数，因此它基本上都是盐，并且已经足够随机了。

【解决方案4】：

根据Robust Defenses for Cross-Site Request Forgery by Barth, Jackson and Mitchell看来，会话标识符的HMAC是最好的通用解决方案。

根据那篇论文，即使在使用 TLS/SSL/HTTPS 时，与服务器状态存储中的会话 ID 不匹配的会话独立 nonce 也容易受到主动网络攻击。会话标识符的 HMAC 没有类似的漏洞。只要您将 nonce 与服务器上的会话 id 匹配，而不是将 POST 参数与 Cookie 标头进行数学运算，会话独立的 nonce 就可以了。

【讨论】：

hmac 比直接哈希要好得多，但我仍然会使用 /dev/urandom，因为 hmac 可以强制离线。
@Rook：你真的声称暴力破解 HMAC-SHA1（假设密钥至少有 128 位熵）是真正的威胁吗？

【解决方案5】：

使用哈希 PHPSESSID 以外的令牌，然后将令牌存储在会话中。此外，令牌应仅对单次提交有效。

【讨论】：

您应该每次都更改它。特别是如果您的页面不是通过 SSL 交付的。（他们应该是！）
不，不，你不应该这样做，除非你想打破所有人的标签式浏览并限制他们只在一个标签中打开你的网站。
@blowdart：为什么使用一次性令牌会破坏标签式浏览？如果您跟踪多个令牌，您仍然可以将它们单独使用，而不会干扰多个选项卡。
嗯，CSRF 缓解的经典方法是在表单和 cookie 中都有一个令牌。您不会接触会话，因为会话会跨越多个主机并且它们会超时。一旦您切换到在每个请求上重新生成金丝雀，cookie 就会被覆盖，然后多个选项卡支持就会消失。使用会话来保存东西通常被认为是不安全的，会话劫持等等。
@blowdart：这对我来说没有任何意义。拥有 HTTP 会话的全部目的是将数据绑定到特定会话。如果您不使用会话来保存特定于会话的数据，那么您将在哪里存储真正的金丝雀值？如果仅将其存储在 cookie 中，您将如何使用它验证请求？其次，如果他们已经劫持了你的会话，那么他们就不需要 CSRF。最后，即使您使用 cookie 来存储您的真实金丝雀值，也没有理由不能在单个 cookie 中存储多个金丝雀值或使用多个 cookie。