html 写入cookie,html - 本地存储与Cookie

在JWT的背景下，Stormpath撰写了一篇相当有用的文章，概述了存储它们的可能方法，以及与每种方法相关的(dis-)优势。

它还简要概述了XSS和CSRF攻击，以及如何对抗它们。

我附上了以下文章的一些简短片段，以防他们的文章脱机/他们的网站出现故障。

本地存储

问题：

Web存储(localStorage / sessionStorage)可通过同一域上的JavaScript访问。 这意味着您站点上运行的任何JavaScript都可以访问Web存储，因此可能容易受到跨站点脚本(XSS)攻击。 简而言之，XSS是一种漏洞，攻击者可以在其中注入将在您的页面上运行的JavaScript。 基本的XSS攻击试图通过表单输入注入JavaScript，攻击者发出警报(“你被黑了”); 进入表单以查看它是否由浏览器运行并且可以被其他用户查看。

预防：

为了防止XSS，常见的响应是转义并编码所有不受信任的数据。 但这远非完整的故事。 2015年，现代网络应用程序使用托管在CDN或外部基础架构上的JavaScript。 现代网络应用程序包括用于A / B测试的第三方JavaScript库，漏斗/市场分析和广告。 我们使用像Bower这样的包管理器将其他人的代码导入我们的应用程序。

如果您使用的其中一个脚本遭到入侵，该怎么办？恶毒   JavaScript可以嵌入页面，而Web存储则可以  损害。 这些类型的XSS攻击可以获得每个人的Web存储   在他们不知情的情况下访问您的网站。 这可能就是为什么了   一群组织建议不要存储任何有价值或信任的东西   网络存储中的任何信息。 这包括会话标识符和  令牌。

作为存储机制，Web存储不会强制执行任何安全措施   转让期间的标准。 谁读取Web存储并使用它必须   尽职尽责，确保他们始终通过HTTPS发送JWT   而且从不HTTP。

饼干

问题：

当与HttpOnly cookie标志一起使用时，Cookie无法通过JavaScript访问，并且不受XSS的影响。 您还可以设置安全cookie标记以保证cookie仅通过HTTPS发送。 这是过去利用cookie来存储令牌或会话数据的主要原因之一。 现代开发人员对使用cookie犹豫不决，因为他们传统上需要将状态存储在服务器上，因此破坏了RESTful最佳实践。 如果要在cookie中存储JWT，作为存储机制的Cookie不需要将状态存储在服务器上。 这是因为JWT封装了服务器为请求提供服务所需的一切。

但是，cookie容易受到不同类型的攻击：   跨站点请求伪造(CSRF)。 CSRF攻击是一种攻击   当恶意网站，电子邮件或博客导致用户的时候会发生这种情况   Web浏览器在可信站点上执行不需要的操作   用户当前已通过身份验证。 这是如何利用的   浏览器处理cookie。 Cookie只能发送到域中   这是允许的。 默认情况下，这是最初的域   设置cookie。 无论如何，cookie都将被发送以请求   无论你是在galaxies.com还是hahagonnahackyou.com。

预防：

可以使用同步令牌模式来防止CSRF。 这个   听起来很复杂，但所有现代的Web框架都支持   这个。

例如，AngularJS有一个验证cookie的解决方案   只能通过您的域访问。 直接来自AngularJS文档：

执行XHR请求时，$ http服务从a读取令牌   cookie(默认情况下为XSRF-TOKEN)并将其设置为HTTP标头  (X-XSRF-TOKEN)。 由于只有在您的域上运行的JavaScript才可以   读取cookie，您的服务器可以放心XHR来自   在您的域上运行的JavaScript。 您可以进行此CSRF保护   通过包括一个{

"iss": "http://galaxies.com",

"exp": 1300819380,

"scopes": ["explorer", "solar-harvester", "seller"],

"sub": "tom@andromeda.com",

"xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"

} JWT声明无国籍：

{

"iss": "http://galaxies.com",

"exp": 1300819380,

"scopes": ["explorer", "solar-harvester", "seller"],

"sub": "tom@andromeda.com",

"xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"

}

利用您的Web应用程序框架的CSRF保护使cookie变得摇滚   用于存储JWT的固体。 CSRF也可以被部分阻止   检查API中的HTTP Referer和Origin标头。CSRF   攻击将具有与之无关的Referer和Origin标头   你的申请。

完整的文章可以在这里找到：[https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/]

关于令牌本身的结构，他们还有一篇关于如何最好地设计和实现JWT的有用文章：[https://stormpath.com/blog/jwt-the-right-way/]