Cookie基础
-
why
-
HTTP 1.x是无状态的协议
无状态:有状态:
-
-
what
-
浏览器在浏览网站时存储在用户计算机上的一小段数据。
-
被设计为网站记住状态信息或记录用户的浏览活动
-
记住用户先前在表单字段中输入的信息
-
-
when
-
会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
-
个性化设置(如用户自定义设置、主题等)
-
浏览器行为跟踪(如跟踪分析用户行为等)
-
-
where
-
开发者工具--->Application--->Storage存储树--->Cookie
-
console : document.cookie。
-
-
how---Cookie工作流程
-
Set-Cookie
-
浏览器端
浏览器会把cookie放到请求头一起提交给服务器,cookie携带了会话ID信息。
服务器指定 Cookie 后,浏览器的每次请求都会携带 Cookie 数据(在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上)
服务器会根据cookie辨认用户:由于cookie带了会话的ID信息,可以通过cookie找到对应会话,通过判断会话来判断用户状态。
-
操作cookie
-
前端对cookie进行操作
-
后端服务器操作,可以直接在response上面进行操作
-
-
Cookie属性
"key=name; expires=Sat, 28 May 2021 12:26:00 GMT; domain=.sankuai.com; path=/; secure; HttpOnly"
-
Expires/Max-Age---设置Cookie的生存期
-
Expires=<date> :cookie 的最长有效时间,是绝对时间点
-
Max-Age=<non-zero-digit> :在 cookie 失效之前需要经过的秒数,是相对时间。
-
两种存储类型的Cookie:会话性与持久性,缺省时,为会话性Cookie。
-
Expires 和Max-Age均存在时,Max-Age 优先级更高
-
- Domain---标识作用域
-
Domain=<domain-value> :指定 cookie 可以送达的主机名。
-
设置domain的值,前面带点和不带点的区别:
-
带点:任何subdomain都可以访问,包括父domain
-
不带点:只有完全一样的域名才能访问,subdomain不能访问(但在IE下比较特殊,它支持subdomain访问)
-
-
domain向上通配:一个页面可以为本域和任何父域设置cookie
对cookie读写时,以“通配”的方式判断Domain是否有效
eg:
-
服务器写入Cookie时,当页面为https://about.meituan.com, cookie为X
Set-cookie:
user1=aaa;domain=.meituan.com,path=/; —>domain匹配
user2=bbb;domain= about.meituan.com,path=/; —>domain匹配
user3=ccc;domain=.about.meituan.com,path=/; —>domain匹配
user4=ddd;domain=other.meituan.com,path=/; —>domain不匹配
-
读取:访问:https://about.meituan.com, Cookie: user1=aaa;user2=bbb;user3=ccc;
访问:https://xm.meituan.com, Cookie: user1=aaa;
-
-
若指定了域名,则相当于各个子域名也包含在内。
-
若没有指定,则默认值为当前文档访问地址中的主机部分(但是不包含子域名)。
-
-
path---标识作用域
定义了Web站点上可以访问该Cookie的目录
-
Path=<path-value> :指定一个URL路径,这个路径必须出现在要请求的资源的路径中才可以发送 Cookie 首部。属性默认是'/',这个值匹配的是web的路由
-
Path向下通配:path为/hello:
Set-cookie:
domain=about.meituan.com,path=/; —>path不匹配
domain=about.meituan.com,path=/hello; —>path匹配
domain=about.meituan.com,path=/hello/world/; —>path匹配
-
-
Secure---限制访问Cookie
指定是否使用HTTPS安全协议发送Cookie。标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端。
-
HTTPOnly---限制访问Cookie
可防止客户端脚本通过document.cookie属性访问Cookie,此类 Cookie 仅作用于服务器,有助于保护Cookie不被XSS窃取或篡改。
-
SameSite ---标识作用域
Cookie 允许服务器要求某个 cookie 在跨站请求时不会被发送,从而可以阻止CSRF。它是相对较新的一个字段,所有主流浏览器都已经得到支持了。
-
-
Cookie安全性
-
Cookie带来的安全问题
-
Cookie篡改
-
Cookie 泄漏(欺骗)
-
Cookie 注入
-
CSRF
-
-
Cookie安全防范
-
设置Cookie HttpOnly
可以防止js脚本读取cookie信息,有效的防止XSS攻击。
-
设置Cookie Secure
将cookie的Secure属性设置为true,即cookie只能使用https协议发送给服务器,而https比http更加安全。
-
设置Cookie有效期不要过长,合适即可
-
设置复杂的cookie,加密cookie
(1)cookie的key使用uuid,随机生成;
(2)cookie的value可以使用复杂组合,比如:用户名+当前时间+cookie有效时间+随机数。 -
session和cookie同时使用,防止在Cookies 中存放敏感信息
sessionId虽然放在cookie中,但是相对的session更安全,可以将相对重要的信息存入session。
-
SameSite,防止CSRF攻击
-
SameSite Cookies
-
引入 SameSite 限制的原因
使用SameSite属性明确声明Cookie的使用情况,SameSite属性(在RFC6265bis中定义)的引入使您可以声明cookie是否应限于第一方或同一站点上下文。
SameSite Cookie允许服务器要求某个cookie在跨站请求时不会被发送,从而可以阻止跨站请求伪造攻击(CSRF)。
-
Cookie 被用来做用户追踪,带来用户隐私问题
-
美国部分州颁布了法律法规,要求网站在设置和使用 Cookie 前需要获得用户同意
-
Cookie 存在 CSRF 安全漏洞
-
-
同站(same-site)/跨站(cross-site)
同站(same-site)/跨站(cross-site)和第一方/第三方是等价的,同站(same-site)只要两个URL的eTLD+1相同即可,不需要考虑协议和端口;
eTLD表示有效顶级域名,注册于 Mozilla 维护的公共后缀列表(Public Suffix List)中,例如,.com、.com.cn、.github.io 等(顶级域名TLD是被点分开的最后一段,而eTLD则是根据实际情况人工维护的)。
eTLD+1则表示,有效顶级域名的下一级域名,那么同一站点就是指顶级域名后缀加上后缀之前的那一部分域名。例如e.shangou.sankuai.com 的 eTLD+1 是 sankuai.com,ones.sankuai.com的 eTLD+1也是 sankuai.com,同站。
e.g.:
-
e.shangou.sankuai.com 的 eTLD+1 是 sankuai.com,ones.sankuai.com的 eTLD+1也是 sankuai.com,不同源但同站。
-
www.meituan.com和www.sankuai.com是跨站
-
a.github.io和b.github.io是跨站
-
-
CSRF攻击与第三方
-
CSRF攻击与第三方关系
通常CSRF攻击都是从第三方站点发起的,要防止CSRF攻击,最好能实现从第三方站点发送请求时禁止Cookie的发送。
浏览器通过不同来源发送HTTP请求时,有如下区别:
-
第三方站点发起的请求,需要浏览器禁止发送某些关键Cookie数据到服务器;
-
同一个站点发起的请求,需要保证Cookie数据正常发送。
-
-
第三方cookie:
https://maoyan.com/?utm_source=meituanweb:
-
并不是所有 Cookie 都是 .maoyan.com 这个域下的,里面还有很多其他域下的 Cookie ,这些所有非当前域下的 Cookie 都属于第三方 Cookie
-
.maoyan.com 这个域下的 Cookie 都属于第一方 Cookie
-
三方cookie实例:
-
登陆https://bj.meituan.com/后跳转到https://maoyan.com/?utm_source=meituanweb,已经不需要再登录了,会自动登录
-
搜索引擎或视频网站上搜索到一些东西,然后打开购物网站就可以收到各种你兴趣的相关推荐,这已经是大众习以为常的事情了,各大购物网站、广告商,会通过第三方 Cookie 收集你的年龄、性别、浏览历史等从而判断你的兴趣喜好,然后带给你精准的信息推荐。这是因为某些网站悄悄的通过三方 Cookie 把你的个人信息运送到了他们那边进行数据挖掘、分析以及用户行为画像,我们的每一次搜索、每一次购买、都会让它变的更精准,最后收到精准的推荐。
-
-
-
禁用第三方 Cookie
Safari、微软、Mozilla已禁用了第三方 Cookie,Chrome也决定将完全禁用第三方 Cookie。由于目前许多网站都依赖三方cookie,在完全不能写入三方 Cookie 的情况下,将会对前端的数据读写方式,甚至是整个广告行业带来巨大影响。
Safari完全禁用三方cookie:https://maoyan.com/?utm_source=meituanweb只有一方cookie
-
-
SameSite属性值
值
特点
备注
Strict
Cookies只会在第一方上下文中发送,即禁止第三方网站携带Cookie,跨站点时,任何情况下都不会发送 Cookie。
-
浏览器将只在访问相同站点时发送 cookie,从而可以阻止CSRF。(CSRF攻击之所以能够成功,是因为该请求中所有的用户验证信息都存在cookie中,因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的cookie来通过安全验证。要防止CSRF,关键在于在请求中放入攻击者所不能伪造的信息,并且该信息不存在于cookie之中。)
Lax
Cookies允许与顶级导航一起发送,并将与第三方网站发起的GET请求一起发送,这是浏览器中的默认值。Chrome自80版本开始Lax为默认值
请求类型
例子
Lax
链接
<a href="..."></a>
发送 Cookie
预加载
<link rel="prerender" href="..."/>
发送 Cookie
GET 表单
<form method="GET" action="...">
发送 Cookie
POST 表单
<form method="POST" action="...">
不发送
iframe
<iframe src="..."></iframe>
不发送
AJAX
$.get("...")
不发送
Image
<img src="...">
不发送
Same-site cookies 将会为一些跨站子请求保留,如图片加载或者 frames 的调用,但只有当用户从外部站点导航到URL时才会发送。如 link 链接
None
Cookie将在所有上下文中发送,即允许跨域发送。
-
sameSite=None需要设置secure=true;针对chrome80版本之后的需要在请求中设置sameSite=None,secure,这样iframe才能获取cookie
SameSite属性得到了广泛支持,但不幸的是,它尚未被开发人员广泛采用。开放的默认发送Cookie到处意味着所有用例都可以使用,但使用户容易受到CSRF和意外信息泄漏的影响。
为了鼓励开发人员陈述其意图并为用户提供更安全的体验,IETF提案“ 渐进式更好的Cookies” 提出了两个关键更改:
Chrome自80版本起就实现了这些行为。
- 没有SameSite属性的Cookies,将被视为SameSite=Lax。
- 当设置Cookie的SameSite=None也必须指定Secure。
-
-
SameSite默认为Lax的影响
-
浏览器中所有的跨站的传统post表单请求、iframe、Ajax 请求和图片都将无法携带 cookie。
e.g.:
-
站点的访问地址是 xxx.meituan.com,而业务接口是 e.shangou.com,这就构成了跨站,接口请求因为无法携带 cookie 会直接挂掉。
-
若页面是以 iframe 形式嵌入在其他系统中,而父级 html 与 iframe 页面是跨站的,iframe 页面的请求也会视为跨站状态而无法携带cookie。
-
-
关于sameSite的说明:
-
出现以下情况需更新其SDK版本
-
您的站点被第三方站点iframe的src所使用---通过iframe方式嵌入其他系统
-
您的应用中有post form表单提交到第三方站点。
-
-
解决
-
更新samesite属性,将对应cookie中samesite属性变成了none
-
更改浏览器SameSite:
-
在地址栏输入:chrome://flags/
-
command+f搜索samesite,三个栏目的右侧分别选择“disabled”;在 disabled 状态,chrome 会将未设置 SameSite 属性的 cookie 视为 SameSite=none,也就是和之前的行为一样。
-
-
-
验证是否升级成功
查看对应cookies中的samesite是否携带了Secure,SameSite属性
-
-
参考:
https://en.wikipedia.org/wiki/HTTP_cookie
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cookie
https://blog.csdn.net/weixin_44269886/article/details/102459425
https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-Cookie/SameSite
https://juejin.cn/post/6844904039935655949
https://blog.csdn.net/sinat_36521655/article/details/104844667
cookie安全:https://wenku.baidu.com/view/48f588b1aaea998fcc220eb9.html