有关Web开发Cookie的所有信息

作者:克里斯·小石川

Cookie的简要历史

HTTP或超文本传输​​协议是一种无状态协议。根据Wikipedia的说法,它是一种无状态协议,因为它“不需要HTTP服务器在多个请求的持续时间内保留每个用户的信息或状态”。

今天,您仍然可以通过简单的网站看到此信息–您输入浏览器的URL,浏览器向某处的服务器发出请求,然后服务器返回文件以呈现页面,并且连接已关闭。

现在,假设您需要登录网站以查看某些内容,例如使用LinkedIn。该过程与上述过程基本相同,但是会看到一个表格,用于输入您的电子邮件地址和密码。

您输入该信息,然后浏览器将其发送到服务器。服务器检查您的登录信息,如果一切看起来都很好,它将把呈现页面所需的数据发送回浏览器。

但是,如果LinkedIn确实是无状态的,那么一旦您导航到另一个页面,服务器将不记得您刚刚登录。它将要求您再次输入电子邮件地址和密码,进行检查,然后发送数据以进行渲染。新页面。

那会非常令人沮丧,不是吗?许多开发人员也这样认为,并找到了在Web上创建有状态会话的不同方法。

Lou Montoulli是90年代初期Netscape的开发人员,当时遇到了一个问题–他正在为另一家公司MCI开发一个在线商店,该商店会将商品存储在服务器上每个客户的购物车中。这意味着人们必须首先创建一个帐户,这很慢,而且占用了大量存储空间。

MCI要求将所有这些数据存储在每个客户自己的计算机上。另外,他们希望一切正常,而无需客户先登录。

为了解决这个问题,Lou提出了一个在程序员中已经广为人知的想法:魔术cookie。

魔术cookie或只是cookie,是在两个计算机程序之间传递的少量数据。它们之所以“神奇”,是因为Cookie中的数据通常是随机密钥或令牌,并且实际上仅适用于使用它的软件。

Lou采用了神奇的cookie概念,并将其应用于在线商店,后来又应用于整个浏览器。

现在,您已经了解了它们的历史,下面让我们快速浏览一下如何使用Cookie在网络上创建有状态会话。

Cookie如何运作

想到Cookie的一种方法是,它们有点像您在游乐园中获得的腕带。

例如,当您登录网站时,就像进入游乐园的过程一样。首先,您要买票,然后进入公园时,工作人员会检查您的票并给您腕带。

这就像您登录的方式一样-服务器检查您的用户名和密码,创建并存储会话,生成唯一的会话ID,然后发送回带有该会话ID的Cookie。

(请注意,会话ID不是您的密码,而是完全独立的并且是即时生成的。正确的密码处理和身份验证不在本文的讨论范围之内,但是您可以在此处找到一些深入的指南。)

在游乐园中时,您可以通过显示腕带来进行任何骑行。

同样,当您向登录的网站发出请求时,浏览器会将带有会话ID的cookie发送回服务器。服务器使用您的会话ID检查您的会话,然后返回您请求的数据。

最后,一旦离开游乐园,您的腕带将不再起作用-您无法使用它重新回到公园或进行更多游乐活动。

这就像登出网站一样。您的浏览器将您的注销请求和cookie发送到服务器,服务器将删除您的会话,并让您的浏览器知道删除您的会话ID cookie。

如果您想回到游乐园,则必须购买另一张门票并获得另一个腕带。换句话说,如果您想继续使用该网站,则必须重新登录。

有关Web开发Cookie的所有信息
来源:100秒内的会话与令牌身份验证(YouTube)

这只是如何使用cookie来保持您登录网站的简单示例。它们可以用来记住您对暗模式的设置,跟踪您在网站上的行为等等。

如何使用Cookie

现在您已经了解了cookie的历史以及为什么使用它们,让我们看一下使用cookie的一些局限性,然后深入研究一些简单的示例。

与某些现代替代方法(例如localStorage或)在浏览器中存储数据相比,Cookie的使用受到很大限制sessionStorage。与其他技术相比,这是cookie的摘要:

饼干 本地存储 会话存储
容量 4KB 10MB 5MB
可从访问 任何窗口 任何窗口 同一标签
过期时间 手动设定 绝不 在选项卡上关闭
存储位置 浏览器和服务器 仅浏览器 仅浏览器
发送请求 是的

基于:Cookie,本地存储,会话存储-Beau教授JavaScript(YouTube)

Cookies是一种较老的技术,并且容量非常有限。不过,您可以使用它们做很多事情。它们的体积小巧,使浏览器可以轻松地将每个请求的cookie发送到服务器。

还值得一提的是,出于安全原因,浏览器仅允许cookie在一个域中工作。

因此,如果您通过ally.com登录银行,则cookie将仅在该域及其子域内起作用。例如,您的ally.comcookie将上工作ally.comally.com/about和子域www.ally.com,但没有axos.com

这意味着,即使你有帐户,并在两者都签署ally.comaxos.com,这些网站将无法读取对方的饼干。

重要的是要记住,cookie是随浏览器中的每个请求一起发送的。这非常方便,但是会在以后涉及到一些严重的安全隐患。

最后,如果您从本文中删除了一件事,请记住,cookie是公开读取和发送的,因此,您切勿在其中存储诸如密码之类的敏感信息。

Cookies实际上只是带有键/值对的字符串。尽管您可能会在后端使用更多的cookie,但有时您可能希望在客户端设置cookie。

以下是在原始JavaScript中设置Cookie的方法:

document.cookie = 'dark_mode=true'

然后,当您打开开发者控制台时,单击“应用程序”,然后在站点的“ Cookies”下,您将看到刚添加的cookie:

有关Web开发Cookie的所有信息

如果您仔细查看Cookie,就会发现它的过期日期设置为Session。这意味着,当您关闭标签页/浏览器时,cookie将被销毁。

这可能是您想要的行为,例如具有付款信息的在线商店。

但是,如果您希望Cookie的寿命更长,则需要设置一个有效期。

要设置到期日期,只需设置Cookie的值,然后添加一个expires具有在将来某个时间设置的日期的属性:

document.cookie = 'dark_mode=true; expires=Fri, 26 Feb 2021 00:00:00 GMT' // expires 1 week from now
有关Web开发Cookie的所有信息

JavaScript的Date对象应该使它变得更加容易和灵活。您可以在此处阅读有关该Date对象的更多信息。

或者,您可以将max-age属性与您希望Cookie持续的秒数一起使用:

document.cookie = 'dark_mode=true; max-age=604800'; // expires 1 week from now

然后,当该日期临近时,浏览器将自动删除您的cookie。

不管您的cookie是否有有效期,更新它都很容易。

只需更改Cookie的值,浏览器就会自动将其提取:

document.cookie = "dark_mode=false; max-age=604800"; // expires 1 week from now
有关Web开发Cookie的所有信息

有时,您只希望Cookie可以与网站的某些部分一起使用。根据您网站的设置方式,一种方法是使用path属性。

制作Cookie的方法/about如下:

document.cookie = 'dark_mode=true; path=/about';

现在,您的Cookie将仅适用于/about和其他嵌套子目录,例如/about/team,而不适用于/blog

然后,当您访问“关于”页面并检查cookie时,您将看到它:

有关Web开发Cookie的所有信息

要在JavaScript中删除Cookie,只需将expires属性设置为已过的日期即可:

document.cookie = 'dark_mode=true; expires=Sun, 14 Feb 2021 00:00:00 GMT'; // 1 week earlier

您还可以使用max-age负值并将其传递给它:

document.cookie = 'dark_mode=true; max-age=-60'; // 1 minute earlier

然后,当您检查Cookie时,它就会消失:

有关Web开发Cookie的所有信息

那应该是您在香草JS中使用cookie所需的所有知识。

我们介绍的所有内容都将在紧要关头工作,但是如果您打算广泛使用Cookie,请查看JavaScript CookieCookie Parser之类的库。

Cookie的安全性问题

通常,正确实施Cookie会非常安全。浏览器有很多内置的限制,我们之前已经介绍过,部分原因是该技术的年代久远,而且还可以提高安全性。

尽管如此,坏演员还是有几种方法可以窃取您的cookie并用它来造成严重破坏。

我们将介绍一些可能发生这种情况的常见方法,并研究解决该问题的不同方法。

另外,请注意,所有代码段都将使用原始JavaScript。如果要在服务器上实现这些修补程序,则需要查找语言或框架的确切语法。

中间人攻击

中间人(MitM)攻击描述了广泛的攻击类别,其中攻击者坐在客户端和服务器之间,并拦截两者之间的数据。

有关Web开发Cookie的所有信息
资料来源:中间人攻击及其防范方法

这可以通过多种方式完成:通过访问或收听不安全的网站,模仿公共WiFi路由器,DNS欺骗或通过恶意软件/广告软件(如SuperFish)

这是MitM攻击的高级概述,以及网站如何保护自己和用户。

警告:视频的开头谈论了斯科茨女王玛丽,并生动地描绘了她的斩首。它不是太可怕,但是如果您想避免它,请跳至此时间戳

作为开发人员,通过确保在服务器上启用HTTPS,使用来自受信任的证书颁发机构的SSL证书以及确保代码使用HTTPS而不是不安全的HTTP,可以大大减少MitM攻击的可能性。

就cookie而言,您应该将Secure属性添加到cookie中,以便只能通过安全的HTTPS连接发送它们:

document.cookie = 'dark_mode=false; Secure';

请记住,该Secure属性实际上并不会加密cookie中的任何数据,它只是确保cookie无法通过HTTP连接发送。

但是,坏演员仍然可能会拦截和操纵Cookie。为了防止这种情况的发生,您还可以使用HttpOnly参数:

document.cookie = 'dark_mode=false; Secure; HttpOnly';

CookieHttpOnly只能由服务器访问,而不能由浏览器的Document.cookieAPI访问。这非常适合诸如登录会话之类的事情,在该会话中,只有服务器才真正需要知道您是否已登录到站点,而您不需要该信息客户端。

XSS攻击

XSS(跨站点脚本)攻击描述了当不良行为者向网站注入意想不到的,潜在危险的代码时的攻击类别。

这些攻击非常棘手,因为它们可能会影响访问该网站的每个人。

有关Web开发Cookie的所有信息
来源:跨站点脚本

例如,如果某个站点具有注释部分,并且某人能够将恶意代码包含在注释中,则访问该站点并阅读该注释的每个人都有可能受到影响。

就cookie而言,如果恶意行为者在站点上成功发起XSS攻击,则他们可以获得访问会话cookie的权限,并以另一个已登录用户的身份访问该站点。从那里,他们可以访问其他用户的设置,以该用户的身份购买商品并将其运送到另一个地址,依此类推。

这是一个视频,概述了XSS的不同类型-反射的,存储的,基于DOM的和突变的:

作为开发人员,您将要确保服务器执行“相同来源策略”,并确保正确过滤了从人员那里收到的任何输入。

与防止MitM攻击一样,您应该为使用的任何cookie设置SecureHttpOnly参数:

document.cookie = 'dark_mode=false; Secure; HttpOnly';

CSRF攻击

CSRF(跨站点请求伪造)攻击是指行为不端的人诱骗他人执行意想不到的,潜在的恶意行为。

例如,如果您登录到站点并单击评论中的链接,如果该链接是CSRF攻击的一部分,则可能会导致您无意中更改登录详细信息,甚至删除帐户。

有关Web开发Cookie的所有信息
资料来源:跨站请求伪造

尽管CSRF攻击与XSS攻击在某种程度上相关,特别是反映了有人将恶意代码插入站点的XSS攻击,但每种攻击都基于不同类型的信任。

根据Wikipedia的说法,XSS“利用了用户对特定站点的信任,而CSRF利用了站点在用户浏览器中的信任”。

这是一段解释CSRF基础知识的视频,并提供了一些有用的示例:

至于cookie,一种防止可能的CSRF攻击的方法是使用SameSite标志:

document.cookie = 'dark_mode=false; Secure; HttpOnly; SameSite=Strict';

您可以设置一些值SameSite

  • Lax:不会发送嵌入内容(图像,iframe等)的Cookie,而是在您单击链接或将请求发送到设置了Cookie的来源时发送的。例如,如果您正在访问testing.com并且单击链接转到test.com/about,则浏览器将发送test.com带有该请求的Cookie
  • Strict:仅当您单击链接或从设置了Cookie的来源发送请求时,才会发送Cookie。例如,您的test.comCookie只会在您在附近时发送test.com,而不会来自其他网站,例如testing.com
  • None:无论上下文如何,Cookie都会随每个请求一起发送。如果设置SameSiteNone,则还必须添加该Secure属性。如果可能,最好避免使用此值

主流浏览器的处理方式SameSite略有不同。例如,如果SameSite未在Cookie上设置Lax,默认情况下Google Chrome会将其设置为。

Cookie的替代品

您可能想知道,如果cookie有太多潜在的安全漏洞,为什么我们仍在使用它们?当然,必须有更好的选择。

这些天,您可以使用sessionStoragelocalStorage存储最初使用cookie的信息。对于有状态会话,还有基于令牌的身份验证以及诸如JWT(JSON Web令牌)之类的功能。

虽然似乎您必须在基于Cookie的身份验证或基于令牌的身份验证之间进行选择,但可以同时使用两者。例如,当某人通过浏览器登录时,您可能要使用基于cookie的身份验证,而当某人通过电话应用程序登录时,则要使用基于令牌的身份验证。

为了使事情更加混乱,Auth0等身份验证即服务提供程序允许您同时进行两种身份验证。

点击阅读原文

本文来自投稿,不代表微擎百科立场,如若转载,请注明出处:https://www.w7.wiki/develop/5062.html

发表评论

登录后才能评论