Javascript 使用（加密性强）会话cookie作为CSRF令牌可以吗？

在Reading中，提出的防止此类攻击的方法之一是同步器令牌模式

如果会话令牌加密性强，它是否可以像下面的伪代码中描述的那样作为csrf令牌

客户：

<script>
dom.replace(placeholder, getCookie("session-cookie"))
</script>

<form>
<input type="hidden" name="csrf-cookie" value="placeholder-value"/>
<input type="text" />
</form>

---

页面加载时使用javascript设置cookie，以防止用户在通过电子邮件将页面副本发送给朋友时意外泄漏会话cookie。

外部站点无法检索的任何内容都可以用作CSRF令牌。因此，会话cookie的内容可以满足此要求。

否，您不应该将会话令牌重新用作CSRF令牌。OWASP CSRF预防备忘单给出了不希望将会话标识符用作CSRF令牌的原因：

虽然这种方法可以有效地降低跨站点请求伪造的风险，但在HTTP参数中包括经过身份验证的会话标识符可能会增加会话劫持的总体风险。架构师和开发人员必须确保没有网络设备或自定义应用程序代码或模块显式记录或以其他方式披露HTTP POST参数

及

跨站点脚本攻击还可以利用在HTML中包含会话标识符来绕过HTTPOnly保护。大多数现代浏览器都阻止客户端脚本访问HTTPOnly cookies。但是，如果HTTPOnly会话标识符被放置在HTML中，则这种保护将丢失，因为客户端脚本可以轻松地从DOM中遍历和提取标识符。仍然鼓励开发人员实现本文所述的同步器令牌模式

还有一些关于为什么使用会话id作为CSRF令牌不是一个好主意的想法。提到在普通http连接上进行数据包嗅探以及对其进行中间人攻击的能力是潜在的风险

因此，CSRF令牌必须是一个不同的令牌，否则，如果我们假设攻击者已经知道会话标识符，那么CSRF令牌将很容易被猜测！更具防御性：玩火可能不是一个好主意：没有必要将会话id重新用作CSRF令牌，这样做只会打开另一个可能被利用的攻击面。没有重复使用，不用担心

因此，尽管会话令牌是加密安全的，但在上述假设下，它还应该独立于CSRF令牌（也在概率意义上）。这也是为什么任何实现示例总是从头开始创建令牌的原因

您可以使用加密安全的随机数生成器来创建字节序列，对它们进行十六进制或Base64编码，以获得要嵌入到页面中的字符串。

---

建议长度为128位，假设熵为64位（例如，8个随机字节转换为16字节十六进制字符串）。该序列的长度决定了安全级别：猜测一个10字节的安全随机数（具有80位熵）以2^（-80）的概率成功，这在大多数应用程序中应该足够了。因此，您的最后一个令牌的长度应该是20字节，一个10字节的随机数转换为十六进制编码。

这也是我们怀疑的，但我想确定，因为我可以挖掘的所有示例都为此目的创建了一个新令牌。OP的解决方案只有在没有为会话ID设置httpOnly的情况下才有效，这是不推荐的。我更喜欢使用“将起作用”而不是“很好”，因为在这里的另一个答案中描述了反对这种做法的有效论点。但这不足以检查会话是否以某种方式发送。仅当会话cookie位于tl的url-right？中时，CSRF保护才存在；dr此整个页面：使用会话令牌作为CSRF令牌，但这是暂时的，因为存在现实情况，攻击者可以通过不允许直接获取会话令牌的漏洞获取用户的CSRF令牌。不管怎样，这样的场景都是一件坏事——但是如果您将会话令牌重用为CSRF令牌，那么会话令牌当然也会受到损害，这是非常糟糕的。

if(request.getParameter("csrf-cookie") != user.getSessionCookie())
    print "get out you evil hacker"