Eri*_*rik 6 javascript security csrf web
阅读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>
Run Code Online (Sandbox Code Playgroud)
服务器:
if(request.getParameter("csrf-cookie") != user.getSessionCookie())
print "get out you evil hacker"
Run Code Online (Sandbox Code Playgroud)
在页面加载时使用javascript设置cookie,以防止用户意外泄露会话cookie,例如,如果他们将页面副本通过电子邮件发送给朋友.
不,您不应该将会话令牌重用为CSRF令牌.OWASP CSRF预防备忘单说明了为什么不希望将会话标识符用作CSRF令牌的原因:
虽然此方法在降低跨站点请求伪造的风险方面是有效的,但在HTTP参数中包括经过身份验证的会话标识符可能会增加会话劫持的总体风险.架构师和开发人员必须确保没有网络设备或自定义应用程序代码或模块明确记录或以其他方式公开HTTP POST参数.
和
在HTML中包含会话标识符也可以通过跨站点脚本攻击来利用HTTPOnly保护.大多数现代浏览器都会阻止客户端脚本访问HTTPOnly cookie.但是,如果HTTPOnly会话标识符放在HTML中,则此保护会丢失,因为客户端脚本可以轻松遍历并从DOM中提取标识符.仍然鼓励开发人员实现本文所述的同步器令牌模式.
以下是关于为什么使用会话ID作为CSRF令牌不是一个好主意的更多想法.本文提到了在普通的http连接上进行数据包嗅探以及对它们进行中间人攻击作为潜在风险的能力.
因此,CSRF令牌必须与另一个令牌不同,否则如果我们假设攻击者已经知道会话标识符,那么CSRF令牌将是非常可猜测的!更具防御性:玩火可能不是一个好主意:没有必要重新使用会话ID作为CSRF令牌,这样你只能打开另一个可能被利用的攻击面.没有重用,不用担心.
因此,尽管会话令牌在加密方面是安全的,但它还应该与CSRF令牌独立(也在概率意义上),以便在上述假设下工作.这也是为什么任何实现示例总是从头开始创建令牌的原因.
您可以使用加密安全随机数生成器来创建字节序列,对其进行十六进制或Base64编码,以获取要嵌入页面的字符串. OWASP建议长度为128位,假定64位熵(例如,8个随机字节转换为16字节的十六进制字符串).该序列的长度决定了安全级别:猜测10字节安全随机数(具有80位熵)成功概率为2 ^( - 80),这在大多数应用中都应该足够.所以你的最终令牌应该有20个字节的长度,一个10字节的随机数转换为十六进制编码.
外部站点无法检索到的任何内容都可以用作 CSRF 令牌。所以会话 cookie 的内容就适合这个。
| 归档时间: |
|
| 查看次数: |
1129 次 |
| 最近记录: |