我已经看到这个问题在SO和许多博客中提出并回答,但是我从来没有看到真正满足我的答案.
这个问题最初是在它征求意见的基础上,而且我的原来的措词是正确的.所以让我在这里清楚地表明,我不希望有一个基于开发者懒惰的模糊概念的意见 – 这就是基本规则是要消除的.我想要的是证据支持是/否答案.或者：
>“是的,可以保护cookies不受XSS和CSRF的影响,如何”或
>“不,通过保护你的cookies从CSRF,你总是打开它们,使同样的XSS攻击使Cookie成为一个好主意”
所以我要重申一下这个问题,一些简化的基本规则,并提前指出漏洞,让你,专家,可以让我直率.
基本原则
>您的应用程序是一个JavaScript浏览器应用程序 – 它可能在AngularJS中,但它可能是定制的.它通过REST调用与服务器进行通信.我们来说,jQuery $ajax调用.
>服务器是无状态的：没有会话管理.
>应用程序用户JWT作为主要身份验证令牌(OAuth2说明中的“访问令牌”),并使用秘密签名密钥在服务器上对其进行验证
>忽略Cookie的其他重要优点：浏览器管理,编码不好的机会不足等.对于这场战斗,我想考虑绝对的安全性,并假设我们可以胜任地编码任何一种机制.
>忽略Cookie的其他缺点,如非浏览器应用程序等.对于这场战斗,我们只关心基于浏览器的JavaScript应用程序.
>您是否使用标头或请求正文以非Cookie方式传输令牌无关紧要;如果您使用本地存储与会话存储 – 也不会忽略任何安全差异.是的,我知道,技术上Cookies使用标题,忽略它.
简而言之,我们只想比较浏览器句柄与您的JavaScript-handle-token,以及比较XSS和CSRF的安全风险.
参赛者
在红角,Auth0：本地存储打破Cookies,因为XSS比CSRF更容易修复
在蓝色的角落,Stormpath：Cookies敲击标题,因为实际上CSRF比XSS更容易修复.
(以下详细摘录两个论点)
武器的选择
XSS和CSRF(我们将可以互换使用CSRF和XSRF：C似乎在文档中更受欢迎,X代码中)
这是我的攻击类型的超简化摘要：
让我们假设您的无状态,JWT认证的JavaScript浏览器应用程序用于网上银行,攻击者“邪恶公司”希望提交一个AJAX REST呼叫,通过冒充您的用户将资金转移到其帐户.
XSS(跨站脚本)
(正如Stormpath指出的那样,有很多攻击媒介 – 我会选择一个)
邪恶公司为您用于密码输入的漂亮文本字段小部件购买github帐户权限.他们知道您的银行网站使用它,所以他们更新它,以提交AJAX请求,以便在您输入您的通行字并按Enter键时将资金转入其帐户.您的构建系统愚蠢地提取更新并投入生产.
CSRF(跨站点请求伪造)
Evil Corp知道您的银行网站使用Cookie中的JWT进行身份验证交易,因此他们编写了一个网络应用程序,提交AJAX请求以将资金转入其帐户.他们在自己的evil.com网站上托管,并通过电子邮件(网络钓鱼)或其他方式引诱您,当您恰好在另一个标签中登录到您的银行网站时.浏览器提交来自evil.com的请求,但是请附上您的JWT,因为它将发送到正确的站点：银行.
标准防御
对于XSS的防御是非常小心您的站点中的代码,以便您永远不让浏览器处理用户不进行消毒(除去javascript和html)以及所有第三方库(Evil的文本框)被使用前审查.正如Stormpath正确指出的那样,这是难以接近的.
对CSRF的防范是使用一种双重提交cookie的形式.这意味着我们的服务器创建了一个令牌(安全随机的字符串),并将它发送到我们的Javascript浏览器应用程序中,可读的cookie(按照惯例称之为“XSRF-TOKEN”),我们的Javascript会在每个请求的头部或正文中发回它.
实际上,double-sumbit-cookie只是一个防御agasint CSRF,但其他一些需要有状态的服务器会话,没有其他(我想！)提供更好的保护.无状态可以通过将令牌放在JWT中,并将服务器端与标题或正文中的内容进行比较来实现.
但是,这种防御的真正的CSRF破坏性质量是同源的政策意味着只有我们的应用程序从我们的域中加载的javascript才能读取该cookie.所以即使javascript on evilcorp.com可以发送我们的cookie的请求,它也不能嵌入我们的XSRF-TOKEN,因为它不能首先读取它.
要真正简化CSRF：
> CSRF攻击工作,因为附加Cookie的浏览器仅依赖于请求的目的地.
> CSRF防御工作,因为Javascript访问cookie取决于Javascript的起源.
Auth0的论点
It’s easier to deal with XSS than XSRF Cookies have this feature that
allows setting anHttpOnlyflag from server side so they can only be
accessed on the server and not from JavaScript. This is useful because
it protects the content of that cookie to be accessed by injected
client-side code (XSS). Since tokens are stored in local/session
storage or a client side cookie,they are open to an XSS attack
getting the attacker access to the token. This is a valid concern,and
for that reason you should keep your tokens expiration low.But if you
think about the attack surface on cookies,one of the main ones is
XSRF. The reality is that XSRF is one of the most misunderstood
attacks,and the average developer,might not even understand the
risk,so lots of applications lack anti-XSRF mechanism. However,
everybody understands what injection is. Put simply,if you allow
input on your website and then render that without escaping it,you
are open to XSS. So based on our experience,it is easier to protect
against XSS than protecting against XSRF. Adding to that,anti-XSRF is
not built-in on every web framework. XSS on the other hand is easy to
prevent by using the escape syntax available by default on most
template engines.
07002
Stormpath的论点
Stormpath recommends that you store your JWT in cookies for web
applications,because of the additional security they provide,and the
simplicity of protecting against CSRF with modern web frameworks.
HTML5 Web Storage is vulnerable to XSS,has a larger attack surface
area,and can impact all application users on a successful attack.
07003
也：
I see a lot of discussions where cookies are pitted against access
tokens. While we’ve all been burned by systems that store a session ID
in a cookie,and that cookie is not secured and thus gets stolen. That
sucks,but its not a reason to use tokens. Its a reason to avoid
non-secure,non-https cookies.
07004
我的礼物
Stormpath对cookies的观点非常有说服力,但有一个洞,我看不清楚它们是否清晰：
双重提交CSRF防御依赖于我的CSRF攻击者无法访问我的cookie：其中包含XSRF-TOKEN的cookie.但是,在本地存储的XSS攻击中,Cookie并不是那么脆弱吗？
一个XSS漏洞可以在我的域上运行javascript,所以它可以读取相同的cookies我的javascript可以. (浏览器不知道这不是我的Javascript)
从另一方面来看：本地存储由同源的策略保护,就像可读的cookie一样.如果我使用Auth0方法,而XSS攻击者知道如何在本地存储中找到我的JWT并使用它.不能同样的攻击者使用相同的XSS脚本抓住我的XSRF-TOKEN cookie并使用它？
这两个攻击都要求他们阅读和理解我的JavaScript应用程序,但是它们的浏览器就是这样.
那有什么区别呢？一个比另一个更安全,为什么？
解决方法
要么
根据其他标准选择适合您的方法,因为两者同样安全,同样不安全.
如果你使用cookies,你一定要使用double-submit-cookie防御,或者类似的东西,因为它在没有XSS的情况下保护你免于CSRF.也就是说,如果你不这样做,你肯定会对其他领域的CSRF攻击开放,甚至不需要XSS漏洞进行工作.
但是无论哪种方式,您的源代码都是公开的(浏览器中的JavaScript),所以对于一个积极的黑客来说,找到从本地存储和阅读XSRF-TOKEN cookie之间找到哪个令牌的努力没有显着差异.如果Evil Corp可以在您的域中运行一些JavaScript,那就是XSS,那么你就被踢了.
您可能需要考虑的与安全无关的标准：
> Cookies很方便,因为您不必编写JavaScript代码来管理令牌 – 只有XSRF.
>如果要使用重定向也会自动更新一次.
>本地存储更容易适应非浏览器应用程序 – 从服务器的角度来看,这是因为如果您使用Java编写的Android应用程序不想处理Cookie,则您的服务器不需要进行任何操作在浏览器和浏览器之间的区别,因为它不使用cookie.
无论如何,自己的想法,但要注意您写的JavaScript和您使用的第三方JavaScript！
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。