它是确定使用（保密性强）会话cookie作为CSRF令牌？(Is it ok to use the

阅读OWASP CSRF预防小抄，方法之一提出，以防止这些类型的攻击是同步标记模式。

如果会话令牌是保密性强，如以下伪描述可以在兼作CSRF令牌？

客户：

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

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

服务器：

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

设置cookie使用JavaScript在页面加载，以防止用户意外泄露会话cookie，如果他们例如在网页的副本通过电子邮件发送给朋友。

Answer 1:

不能由外部站点检索什么都可以用作CSRF令牌。因此，会话cookie的内容是罚款这一点。

Answer 2:

不，你不应该重用会话令牌作为您的CSRF令牌。为什么使用会话标识符作为CSRF令牌是不希望的OWASP CSRF预防速查表给出的原因：

虽然这种方法是有效的减轻跨站请求伪造的危险性，其中包括在HTTP参数认证的会话标识符可以增加会话劫持的总体风险度。架构师和开发人员必须确保没有网络设备或自定义应用程序代码或模块明确记录或以其他方式披露HTTP POST参数。

和

内HTML会话标识符的夹杂物也可以通过跨站点脚本攻击利用绕过中HTTPOnly保护。大多数现代浏览器会阻止客户端脚本访问中HTTPOnly饼干。然而，如果中HTTPOnly会话标识符被置于内HTML作为客户端脚本可以很容易地穿过并提取从DOM标识符这种保护丢失。开发商仍鼓励这篇文章中描述来实现同步标记模式。

下面是一些关于为什么它可能是不是一个好主意，使用会话ID作为CSRF令牌更多的心思。这篇文章提到，在普通的HTTP连接，并做他们人在这方面的中间人攻击的潜在风险的能力包嗅探。

因此，至关重要的是，CSRF令牌是一个不同的，否则，如果我们假设攻击者已经知道会话标识符的CSRF令牌是平凡猜测的！把更多的防守：这可能是不玩火一个好主意：有没有必要重新使用会话ID作为CSRF令牌，这样做你只打开一个可能被利用的另一个攻击面。不重用，没有关于后顾之忧。

因此，尽管会话令牌加密保护，但还应该从CSRF令牌是独立的（也是在概率意义上的）整个事情按照上述假设工作。这也是为什么所有的实施例子总是从头开始创建自己的令牌。

你可以使用加密安全随机数生成器来创建字节，六角形或Base64编码他们获得一个字符串，它是要在页面中嵌入的序列。 OWASP建议的128个比特，其中它们呈现熵的64个比特的长度（例如，8个字节的随机变换为16字节的十六进制字符串）。该序列的长度确定的安全级别：猜测10字节安全随机数（其具有80个比特的熵）与概率2 ^成功（ - 80），这应该在大多数应用中是足够的。因此，最终的令牌应该有20个字节的长度，转换为十六进制编码一个10字节的随机数。