本地存储与 Cookie

发布于 2024-09-09 02:49:47 字数 1433 浏览 3 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

赠佳期 2024-09-16 02:49:47

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

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

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

无论哪种方式,您都希望将会话 cookie 作为 cookie 保留。

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

  1. 除了是旧方式之外在保存数据时,Cookie 给您的限制是 4096 字节(实际上是 4095)——这是针对每个 cookie 的。本地存储大小为每个域 10MB - 此堆栈溢出问题也提到了。

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

Cookies and local storage serve different purposes. Cookies are primarily for reading server-side, local storage can only be read by the client-side. So the question is, in your app, who needs this data — the client or the server?

If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.

If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.

You'll want to leave your session cookie as a cookie either way though.

As per the technical difference, and also my understanding:

  1. Apart from being an old way of saving data, Cookies give you a limit of 4096 bytes (4095, actually) — it's per cookie. Local Storage is as big as 10MB per domainthis Stack Overflow question also mentions it.

  2. localStorage is an implementation of the Storage Interface. It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data — unlike cookie expiry.

入怼 2024-09-16 02:49:47

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

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

我附上了下面文章的一些简短片段,以防他们的文章离线/网站瘫痪。

本地存储

问题:

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

预防:

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

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

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

Cookie

问题:

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

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

预防:

现代浏览器支持SameSite标志,以及HttpOnlySecure。该标志的目的是防止跨站请求中传输cookie,防止多种CSRF攻击。

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

例如,AngularJS 有一个解决方案来验证 cookie 是否为
仅可由您的域访问。直接来自 AngularJS 文档:

当执行 XHR 请求时,$http 服务从
cookie(默认情况下为 XSRF-TOKEN)并将其设置为 HTTP 标头
(X-XSRF-令牌)。因为只有在您的域上运行的 JavaScript 才能
读取cookie,您的服务器可以确信XHR来自
JavaScript 在您的域上运行。你可以做这个CSRF保护
通过包含 xsrfToken JWT 声明实现无状态:

<前><代码>{
"iss": "http://galaxies.com",
“经验”:1300819380,
"scopes": ["explorer", "solar-harvester", "seller"],
"sub": "[电子邮件受保护]",
“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/

In the context of JWTs, Stormpath have written a fairly helpful article outlining possible ways to store them, and the (dis-)advantages pertaining to each method.

It also has a short overview of XSS and CSRF attacks, and how you can combat them.

I've attached some short snippets of the article below, in case their article is taken offline/their site goes down.

Local Storage

Problems:

Web Storage (localStorage/sessionStorage) is accessible through JavaScript on the same domain. This means that any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks. XSS in a nutshell is a type of vulnerability where an attacker can inject JavaScript that will run on your page. Basic XSS attacks attempt to inject JavaScript through form inputs, where the attacker puts alert('You are Hacked'); into a form to see if it is run by the browser and can be viewed by other users.

Prevention:

To prevent XSS, the common response is to escape and encode all untrusted data. But this is far from the full story. In 2015, modern web apps use JavaScript hosted on CDNs or outside infrastructure. Modern web apps include 3rd party JavaScript libraries for A/B testing, funnel/market analysis, and ads. We use package managers like Bower to import other peoples’ code into our apps.

What if only one of the scripts you use is compromised? Malicious
JavaScript can be embedded on the page, and Web Storage is
compromised. These types of XSS attacks can get everyone’s Web Storage
that visits your site, without their knowledge. This is probably why a
bunch of organizations advise not to store anything of value or trust
any information in web storage. This includes session identifiers and
tokens.

As a storage mechanism, Web Storage does not enforce any secure
standards during transfer. Whoever reads Web Storage and uses it must
do their due diligence to ensure they always send the JWT over HTTPS
and never HTTP.

Cookies

Problems:

Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript, and are immune to XSS. You can also set the Secure cookie flag to guarantee the cookie is only sent over HTTPS. This is one of the main reasons that cookies have been leveraged in the past to store tokens or session data. Modern developers are hesitant to use cookies because they traditionally required state to be stored on the server, thus breaking RESTful best practices. Cookies as a storage mechanism do not require state to be stored on the server if you are storing a JWT in the cookie. This is because the JWT encapsulates everything the server needs to serve the request.

However, cookies are vulnerable to a different type of attack:
cross-site request forgery (CSRF). A CSRF attack is a type of attack
that occurs when a malicious web site, email, or blog causes a user’s
web browser to perform an unwanted action on a trusted site on which
the user is currently authenticated. This is an exploit of how the
browser handles cookies. A cookie can only be sent to the domains in
which it is allowed. By default, this is the domain that originally
set the cookie. The cookie will be sent for a request regardless of
whether you are on galaxies.com or hahagonnahackyou.com.

Prevention:

Modern browsers support the SameSite flag, in addition to HttpOnly and Secure. The purpose of this flag is to prevent the cookie from being transmitted in cross-site requests, preventing many kinds of CSRF attack.

For browsers that do not support SameSite, CSRF can be prevented by using synchronized token patterns. This
sounds complicated, but all modern web frameworks have support for
this.

For example, AngularJS has a solution to validate that the cookie is
accessible by only your domain. Straight from AngularJS docs:

When performing XHR requests, the $http service reads a token from a
cookie (by default, XSRF-TOKEN) and sets it as an HTTP header
(X-XSRF-TOKEN). Since only JavaScript that runs on your domain can
read the cookie, your server can be assured that the XHR came from
JavaScript running on your domain. You can make this CSRF protection
stateless by including a xsrfToken JWT claim:

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

Leveraging your web app framework’s CSRF protection makes cookies rock
solid for storing a JWT. CSRF can also be partially prevented by
checking the HTTP Referer and Origin header from your API. CSRF
attacks will have Referer and Origin headers that are unrelated to
your application.

The full article can be found here:
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

They also have a helpful article on how to best design and implement JWTs, with regards to the structure of the token itself:
https://stormpath.com/blog/jwt-the-right-way/

童话 2024-09-16 02:49:47

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

Cookie 的

优点

  • 传统支持(永远存在)
  • 持久数据
  • 过期日期
  • Cookie 可以标记为 HTTPOnly,这可能会在用户会话期间限制对用户浏览器的 XSS 攻击(不能保证完全免受 XSS 攻击)。

每个

  • 域将其所有 cookie 存储在一个字符串中,这可以使
    解析数据很困难
  • 数据未加密,这成为一个问题,因为......虽然
    尺寸小,cookie 随每个 HTTP 请求一起发送 大小有限
    (4KB)

本地存储

优点

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

缺点

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

localStorage 的用法与会话几乎相同。它们有非常精确的方法,因此从会话切换到 localStorage 确实是小菜一碟。但是,如果存储的数据对于您的应用程序确实至关重要,您可能会使用 cookie 作为备份,以防 localStorage 不可用。如果您想检查浏览器对 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
}

“安全 (SSL) 页面上的 localStorage 值是隔离的”
正如有人注意到的那样,请记住 localStorage 不会
如果您从“http”切换到“https”安全协议,则可用,其中
cookie 仍然可以访问。这对于
请注意您是否使用安全协议。

With localStorage, web applications can store data locally within the user's browser. Before HTML5, application data had to be stored in cookies, included in every server request. Large amounts of data can be stored locally, without affecting website performance. Although localStorage is more modern, there are some pros and cons to both techniques.

Cookies

Pros

  • Legacy support (it's been around forever)
  • Persistent data
  • Expiration dates
  • Cookies can be marked as HTTPOnly which might limit XSS atacks to user browser during his sesion (does not guarantee full immunity to XSS atacks).

Cons

  • Each domain stores all its cookies in a single string, which can make
    parsing data difficult
  • Data is unencrypted, which becomes an issue because... ... though
    small in size, cookies are sent with every HTTP request Limited size
    (4KB)

Local storage

Pros

  • Support by most modern browsers
  • Persistent data that is stored directly in the browser
  • Same-origin rules apply to local storage data
  • Is not sent with every HTTP request
  • ~5MB storage per domain (that's 5120KB)

Cons

  • Not supported by anything before: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
  • If the server needs stored client information you purposely have
    to send it.

localStorage usage is almost identical with the session one. They have pretty much exact methods, so switching from session to localStorage is really child's play. However, if stored data is really crucial for your application, you will probably use cookies as a backup in case localStorage is not available. If you want to check browser support for localStorage, all you have to do is run this simple script:

/* 
* 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
}

"localStorage values on Secure (SSL) pages are isolated"
as someone noticed keep in mind that localStorage will not be
available if you switch from 'http' to 'https' secured protocol, where
the cookie will still be accesible. This is kind of important to
be aware of if you work with secure protocols.

葬﹪忆之殇 2024-09-16 02:49:47

Cookie

  1. 在 HTML5 之前引入。
  2. 有有效期。
  3. 通过 JS 或通过浏览器清除浏览数据或过期后清除。
  4. 将根据每个请求发送到服务器。
  5. 容量为4KB。
  6. 只有字符串才能存储在 cookie 中。
  7. 有两种类型的 cookie:持久性 cookie 和会话 cookie。

本地存储

  1. 随 HTML5 引入。
  2. 没有有效期。
  3. 通过JS或者浏览器的清除浏览数据来清除。
  4. 您可以选择何时必须将数据发送到服务器。
  5. 容量为5MB。
  6. 数据无限期存储,并且必须是字符串。
  7. 只有一种类型。

Cookies:

  1. Introduced prior to HTML5.
  2. Has expiration date.
  3. Cleared by JS or by Clear Browsing Data of browser or after expiration date.
  4. Will sent to the server per each request.
  5. The capacity is 4KB.
  6. Only strings are able to store in cookies.
  7. There are two types of cookies: persistent and session.

Local Storage:

  1. Introduced with HTML5.
  2. Does not have expiration date.
  3. Cleared by JS or by Clear Browsing Data of the browser.
  4. You can select when the data must be sent to the server.
  5. The capacity is 5MB.
  6. Data is stored indefinitely, and must be a string.
  7. Only have one type.
紫竹語嫣☆ 2024-09-16 02:49:47

主要区别:

容量:

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

浏览器支持:

  • 本地存储:< /strong> HTML5
  • Cookie: HTML4、HTML5

存储位置:

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

随请求发送:

  • 本地存储:
  • Cookie:

访问来源:

  • 本地存储:< /strong> 任何窗口
  • Cookie: 任何窗口。

到期日期:

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

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

Key Differences:

Capacity:

  • Local Storage: 10MB
  • Cookies: 4kb

Browser Support:

  • Local Storage: HTML5
  • Cookies: HTML4, HTML5

Storage Location:

  • Local Storage: Browser Only
  • Cookies: Browser & Server

Send With Request:

  • Local Storage: No
  • Cookies: Yes

Accessed From:

  • Local Storage: Any Window
  • Cookies: Any Window.

Expiry Date:

  • Local Storage: Never Expire, until done by javascript.
  • Cookies: Yes, Have expiry date.

Note: Use that, what suits you.

胡大本事 2024-09-16 02:49:47

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

引用自 WayBack Archive of 2018 年关于 Window.localStorage 的 MDN 主题:

注意:从 iOS 5.1 开始,Safari Mobile 将 localStorage 数据存储在缓存文件夹中,该文件夹通常会根据操作系统的要求偶尔进行清理如果空间有限。 Safari Mobile 的隐私浏览模式还可以完全阻止写入 localStorage

It is also worth mentioning that localStorage cannot be used when users browse in "private" mode in some versions of mobile Safari.

Quoted from WayBack Archive of MDN topic on Window.localStorage back in 2018:

Note: Starting with iOS 5.1, Safari Mobile stores localStorage data in the cache folder, which is subject to occasional clean up, at the behest of the OS, typically if space is short. Safari Mobile's Private Browsing mode also prevents writing to localStorage entirely.

晨光如昨 2024-09-16 02:49:47

Cookie:

  • 可以通过JavaScript访问,因此Cookie的数据可以通过XSS窃取
    攻击(跨站脚本攻击)
    ,但设置 HttpOnly 标志
    Cookie 阻止 JavaScript 的访问,因此 Cookie 的数据
    免受XSS 攻击

  • 容易受到CSRF(跨站请求伪造)的攻击,但设置
    SameSite 标志 Lax 设置为 Cookie 可缓解 CSRF 并将 SameSite 标志设置 Strict 设置为 Cookie 防止
    CSRF

  • 必须有到期日期,因此当到期日期过去时,Cookie
    自动删除,因此即使您忘记删除 Cookie
    Cookie 由于过期而被自动删除。

  • 一般大小约为4KB(取决于浏览器)。

本地存储:

  • 可通过JavaScript访问,因此本地存储的数据可能被XSS窃取
    攻击(跨站脚本攻击)
    然后,正如我研究的那样,
    没有简单的方法可以预防本地存储遭受XSS攻击
    攻击

  • 不容易受到CSRF(跨站请求伪造)的攻击。<​​/p>

  • 没有过期日期,因此如果您忘记删除本地存储
    数据
    本地存储数据可以永久保留。

  • 一般大小约为5MB(取决于浏览器)。

我建议对敏感数据使用Cookie,对非敏感数据使用本地存储

Cookie:

  • is accessible by JavaScript so Cookie's data can be stolen by XSS
    attack(Cross Site Scripting attack)
    but setting HttpOnly flag
    to Cookie prevents the access by JavaScript so Cookie's data is
    protected from XSS attack.

  • is vulnerable to CSRF(Cross Site Request Forgery) but setting
    SameSite flag with Lax to Cookie mitigates CSRF and setting SameSite flag with Strict to Cookie prevents
    CSRF.

  • must have expiry date so when expiry date passes, Cookie is
    deleted automatically so even if you forgot to delete Cookie,
    Cookie is deleted automatically because of expiry date.

  • is about 4KB as a common size (depending on browsers).

Local Storage:

  • is accessible by JavaScript so Local Storage's data can be stolen by XSS
    attack(Cross Site Scripting attack)
    then, as logn as I researched,
    there are no easy preventions for Local Storage from XSS
    attack
    .

  • is not vulnerable to CSRF(Cross Site Request Forgery).

  • doesn't have expiry date so if you forgot to delete Local Storage
    data
    , Local Storage data can stay forever.

  • is about 5MB as a common size (depending on browsers).

I recommend using Cookie for sensitive data and Local Storage for non-sensitive data.

诗笺 2024-09-16 02:49:47

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

LOCAL和Session以JSON格式存储数据,因此易于解析。但cookies数据是字符串格式的。

本地存储vs 会话存储 vs cookie

图片参考:https:// tutorial.techaltum.com/local-and-session-storage.html

Local storage can store up to 5mb offline data, whereas session can also store up to 5 mb data. But cookies can store only 4kb data in text format.

LOCAl and Session storage data in JSON format, thus easy to parse. But cookies data is in string format.

Local Storage vs Session Storage Vs cookies

Image reference: https://tutorial.techaltum.com/local-and-session-storage.html

開玄 2024-09-16 02:49:47

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

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

Well, local storage speed greatly depends on the browser the client is using, as well as the operating system. Chrome or Safari on a mac could be much faster than Firefox on a PC, especially with newer APIs. As always though, testing is your friend (I could not find any benchmarks).

I really don't see a huge difference in cookie vs local storage. Also, you should be more worried about compatibility issues: not all browsers have even begun to support the new HTML5 APIs, so cookies would be your best bet for speed and compatibility.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文