本地存储与Cookie

时间:2010-07-10 20:02:10

标签: html cookies httprequest local-storage

我希望通过将所有Cookie移动到本地存储来减少我网站上的加载时间,因为它们似乎具有相同的功能。除了明显的兼容性问题之外,使用本地存储替换cookie功能是否有任何优缺点(特别是在性能方面)?

8 个答案:

答案 0 :(得分:1148)

Cookie和本地存储有不同的用途。 Cookie主要用于读取服务器端,本地存储只能由客户端读取。所以问题是,在你的应用中,谁需要这些数据 - 客户端还是服务器?

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

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

您希望将会话Cookie保留为cookie。

根据技术差异,以及我的理解:

  1. 除了作为一种保存数据的旧方法外,Cookie还为您提供 4096 字节(实际为4095)的限制 - 每个cookie。本地存储量大到每个域5MB - SO Question 也提到它

  2. localStorageStorage接口的实现。它存储无截止日期的数据,并通过JavaScript清除 ,或清除浏览器缓存/本地存储的数据 - 与Cookie过期不同。

答案 1 :(得分:173)

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

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

我已附上以下文章的一些简短摘录,以防他们的文章脱机/他们的网站停播。

本地存储

<强>问题:

  

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

<强>预防:

  

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

     

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

     

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

缓存

<强>问题:

  

Cookie与HttpOnly 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 docs:

     

执行XHR请求时,$ http服务从a读取令牌   cookie(默认情况下为XSRF-TOKEN)并将其设置为HTTP标头   (X-XSRF-TOKEN)。由于只有您的域上运行的JavaScript才可以   读取cookie,您的服务器可以放心XHR来自   您的域上运行的JavaScript。您可以进行CSRF保护   包含xsrfToken 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/

答案 2 :(得分:80)

使用localStorage,Web应用程序可以在用户的​​浏览器中本地存储数据。在HTML5之前,应用程序数据必须存储在cookie中,包含在每个服务器请求中。可以在本地存储大量数据,而不会影响网站性能。虽然localStorage更现代,但这两种技术都有一些优点和缺点。

缓存

赞成

  • 遗产支持(它永远存在)
  • 持久数据
  • 到期日期

缺点

  • 每个域将其所有cookie存储在一个字符串中,这可以生成 难以解析数据
  • 数据未加密,这成为一个问题,因为......但是 如果规模较小,则每次HTTP请求都会发送cookie限制大小 (4KB)
  • 可以从cookie执行SQL注入

本地存储

赞成

  • 大多数现代浏览器的支持
  • 直接存储在浏览器中的持久数据
  • 同源规则适用于本地存储数据
  • 不会随每个HTTP请求一起发送
  • 每个域
  • ~5MB存储空间(即5120KB)

缺点

  • 之前不支持任何内容:IE 8,Firefox 3.5,Safari 4,Chrome 4,Opera 10.5,iOS 2.0,Android 2.0
  • 如果服务器需要您有意拥有的存储客户端信息 发送它。

localStorage用法几乎与会话一致。他们有非常精确的方法,所以从会话切换到localStorage真的是孩子的游戏。但是,如果存储的数据对您的应用程序非常重要,那么在localStorage不可用的情况下,您可能会使用cookie作为备份。如果您想检查localStorage的浏览器支持,您只需运行这个简单的脚本:

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}
  

&#34;安全(SSL)页面上的localStorage值被隔离&#34;   正如有人注意到的那样,请记住localStorage不会   如果您从&#39; http&#39;切换到&#39; https&#39;安全协议,在哪里   cookie仍然可以访问。这有点重要   请注意您是否使用安全协议。

答案 3 :(得分:7)

那么,本地存储速度在很大程度上取决于客户端使用的浏览器以及操作系统。 Mac上的Chrome或Safari可能比PC上的Firefox快得多,特别是对于更新的API。一如既往,测试是你的朋友(我找不到任何基准)。

我真的没有看到cookie与本地存储的巨大差异。此外,您应该更担心兼容性问题:并非所有浏览器都开始支持新的HTML5 API,因此Cookie是您速度和兼容性的最佳选择。

答案 4 :(得分:7)

本地存储最多可存储5mb的离线数据,而会话最多可存储5mb的数据。但cookie只能以文本格式存储4kb数据。

LOCAL和Session存储数据采用JSON格式,因此易于解析。但cookie数据是字符串格式。

答案 5 :(得分:7)

值得一提的是,当用户在某些版本的移动版Safari中以“私人”模式浏览时,localStorage无法使用。

引自MDN(https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage):

  

注意:从iOS 5.1开始,Safari Mobile会存储localStorage数据   缓存文件夹,偶尔清理,在   操作系统的要求,通常是空间很短。 Safari Mobile的私有   浏览模式还可以防止完全写入localStorage。

答案 6 :(得分:1)

主要区别:

容量:

  • 本地存储: 10MB
  • Cookies: 4kb

浏览器支持:

  • 本地存储:HTML5
  • Cookie:HTML4、HTML5

存储位置:

  • 本地存储:仅限浏览器
  • Cookie:浏览器和服务器

随请求发送:

  • 本地存储:
  • Cookie:

访问自:

  • 本地存储:任何窗口
  • Cookies:任何窗口。

有效期:

  • 本地存储:永不过期,直到通过 javascript 完成。
  • Cookies:是的,有有效期。

注意:使用那个,适合你的。

答案 7 :(得分:0)

曲奇饼

  

1在HTML5之前引入。

     

2-有到期日期。

     

通过JS或浏览器的清除浏览数据或之后的3-Cleard   到期日期。

     

每个请求都会将4发送到服务器。

     

5-容量为4KB。

     

只有6个字符串可以存储在cookie中。

     

7- cookie分为两种:持久性和会话性。

本地存储

  

1-HTML5引入。

     

2-没有到期日期。

     

通过JS或浏览器的清除浏览数据进行3-Cleard。

     

4-您可以选择何时必须将数据发送到服务器。

     

5-容量为5MB。

     

6-字符串,javascript原语和对象都可以存储在其中。

     

只有7种类型。