Day14-守护饼乾大作战（一）

前言

哈罗大家好，前几天讲完 HTTP Security Headers 之後今天紧接着要讲 cookie，虽然 cookie 也是 header 的一部分，但因为 cookie 自己又有太多属性，所以决定把它独立出来讲

cookie 的部分预计会花三天时间，今明两天先把 cookie 跟安全有关的属性 Secure、HttpOnly、SameSite 讲一讲，接着後天再示范怎麽在 Node.js 跟 Go 里面把这些属性加进 cookie 里～

Secure

首先来讲讲最简单的 Secure 属性，我想大家应该都知道 cookie 会随着请求一起发出去，所以若是请求发起时没有使用 HTTPS，那 cookie 就也会以明文传送，一不小心可能就会在路上被劫走 session ID，非常的不安全

为了解决这个问题，後来 cookie 就多了一个 Secure 属性可以设定，只要你把这个属性设定上去，那浏览器在发送 cookie 之前就会先看这个请求有没有 HTTPS，有的话 cookie 才会一并出去

因为这个属性实在太重要，现在应该大部分网站都有用了，像我刚刚上 Facebook 看他的 cookie 就全部都有 Secure 属性，不然 cookie 被偷走真的太麻烦

HttpOnly

在以前没有 HttpOnly 的时代，万一你浏览的网站不小心中了 XSS 攻击，也就是说那个网站上有骇客植入的脚本，那个恶意的 JS 脚本就可以直接透过 document.cookie 拿到你浏览器上储存的 cookie。拿到 cookie 之後，这个恶意脚本可以把这些 cookie 发送到骇客自己的服务器，此後就可以使用这些 session cookie 来到用你的身份

你可能会说「那工程师应该想办法让网站不要有 XSS 漏洞不是吗？」，虽然话是这麽说没错，但跟资安有关的东西都很难做到百分之百，所以应该要做到即便网站中了 XSS 攻击，骇客也没办法偷走 cookie

所以 HttpOnly 就是为此而来的，当你的 cookie 被加上 HttpOnly 属性之後，那个 cookie 还是会跟着请求一起被发出去，但他就没办法被 JS 脚本存取，因此即便有骇客成功在网站上植入恶意脚本，那个脚本也拿不到你的 cookie，使用者的身份就也不会被盗用

因为这个属性限缩了 XSS 攻击能做到的事，所以很多网站都会在比较重要的 session cookie 上加上 HttpOnly，至於其他需要在浏览器上存取、而且被偷走好像也没差的，就不加也没关系～

小结

今天介绍了 Secure 跟 HttpOnly 这两个 cookie 属性，接着明天要讲的是 CSRF 攻击跟 cookie 的 SameSite 属性

如果对於今天的内容有什麽问题欢迎在下方留言，没问题的话那就明天见罗～