本地存储与 Cookie

Question

我想通过将所有 cookie 移动到本地存储来减少我网站上的加载时间，因为它们似乎具有相同的功能。除了明显的兼容性问题外，使用本地存储替换 cookie 功能是否有任何优点/缺点（尤其是性能方面）？

原文由 Gio Borje 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

Cookie 和本地存储有不同的用途。 Cookies主要用于 服务端 读取，本地存储只能由 客户端 读取。所以问题是，在您的应用程序中，谁需要这些数据——客户端还是服务器？

如果它是您的客户端（您的 JavaScript），那么一定要切换。您通过在每个 HTTP 标头中发送所有数据来浪费带宽。

如果它是您的服务器，本地存储就没那么有用，因为您必须以某种方式转发数据（使用 Ajax 或隐藏的表单字段或其他方式）。如果服务器只需要每个请求的总数据的一小部分，这可能没问题。

不过，无论哪种方式，您都希望将会话 cookie 保留为 cookie。

根据技术差异，以及我的理解：

1. 除了作为一种保存数据的旧方法之外，Cookie 还为您提供 4096 字节（实际上是 4095）的限制——这是每个 cookie 的限制。本地存储 每个域有 5MB 大小——SO Question 也提到了它。

2. localStorage 是 Storage 接口的实现。它存储 没有过期日期 的数据，并且 只能 通过 JavaScript 清除，或清除浏览器缓存/本地存储的数据——与 cookie 过期不同。

原文由 jpsimons 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

在 JWT 的上下文中，Stormpath 写了一篇相当有用的文章，概述了存储它们的可能方法，以及与每种方法相关的（缺点）优点。

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

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

本地存储

问题：

Web Storage (localStorage/sessionStorage) 可在同一域中通过 JavaScript 访问。这意味着您网站上运行的任何 JavaScript 都可以访问网络存储，因此容易受到跨站点脚本 (XSS) 攻击。简而言之，XSS 是一种漏洞，攻击者可以在其中注入将在您的页面上运行的 JavaScript。基本的 XSS 攻击试图通过表单输入注入 JavaScript，攻击者在其中放置 alert(‘You are Hacked’);进入一个表单，看看它是否由浏览器运行，是否可以被其他用户查看。

预防：

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

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

作为一种存储机制，Web Storage 在传输过程中不强制执行任何安全标准。任何阅读和使用 Web Storage 的人都必须尽职调查以确保他们始终通过 HTTPS 而不是 HTTP 发送 JWT。

饼干

问题：

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

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

预防：

除了 HttpOnly 和 Secure 之外，现代浏览器还支持 SameSite 标志。这个flag的作用是防止cookie在跨站请求中被传输，防止多种CSRF攻击。

对于不支持 SameSite 的浏览器，可以通过使用同步令牌模式来防止 CSRF。这听起来很复杂，但所有现代 Web 框架都支持这一点。

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

在执行 XHR 请求时，$http 服务从 cookie 中读取令牌（默认情况下为 XSRF-TOKEN）并将其设置为 HTTP 标头（X-XSRF-TOKEN）。由于只有在您的域上运行的 JavaScript 才能读取 cookie，因此您的服务器可以确信 XHR 来自在您的域上运行的 JavaScript。您可以通过包含 xsrfToken JWT 声明使此 CSRF 保护无状态：

 {
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "[e-mail]",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

利用您的 Web 应用程序框架的 CSRF 保护使 cookie 非常适合存储 JWT。还可以通过检查 API 中的 HTTP Referer 和 Origin 标头来部分阻止 CSRF。 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/

原文由 XtraSimplicity 发布，翻译遵循 CC BY-SA 4.0 许可协议