cookie中的SameSite属性

0 我们的网页为什么能被iframe嵌入：

1) 把网关加入应用程序的白名单，Content-Security-Policy是所谓的白名单在http协议上的体现

index A.xxx.net

网关 B.xxx.net 反向代理到C（域名不关心）；A iframe B

证明，用fiddler修改这个头，B的response头不再有https:A.xxx.net，则A嵌入B不成功

2) 跨域cookie，发现应用程序的cookie压根没有设置SameSite

https://blog.csdn.net/weixin_47450807/article/details/123248357

SameSite可以设置为三个属性strict,Lax,None

属性一：strict属性：该属性表示表示完全禁止第三方cookie,也就是在跨站时，均不会携带cookie,只有当前站点的url和访问的站点的url一致时，才能携带cookie。但是我们此时想一种情况，比如说当前站点A存在一个链接，链接到gitte网站，如果我们之前已经登录了gitte网站的话，则我们再次访问该网站时应该是处于登录状态的。但是我们对当前站点cookie设置了SameSite属性为strict值，所以当前跳转链接并不会携带cookie，所以我们的信息无法得到认证，此时就需要重新登录。

Set-Cookie: CookieName=CookieValue; SameSite=strict;

属性二：Lax:该属性比strict的属性要宽松一些，其允许我们在跨站使用get请求时（不准确，比如ajaxget）携带cookie。（重定向和window.open 是get请求）

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

属性三：None属性：chrome默认将Lax设置为默认值，此时我们可以更改samesite的值，将其设置为none,此时必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。
下面是无效的：

Set-Cookie: widget_session=abc123; SameSite=None
下面是有效的：

Set-Cookie: widget_session=abc123; SameSite=None;Secure;

如果我们的网站是一个管理系统，或者是用户较少，经常采用输入网址的方式或者从浏览器的收藏夹中打开该网站时，我们可以使用strict。如果我们做的一些网站例如说博客，当我们在其他站点设置跳转的时候，如果我们使用strict的话，就会设置重新登录，此时我们可以将SameSite的值设置为Lax。
如果我们的网站中存在一些iframe嵌套，如果使用strict和Lax就不会携带cookie进行身份验证，

不支持子域，如果从主域跳转到子域，也不会携带cookie

1 然而，当我做实验时，发现第二点并没有证据

index A.xxx.net

网关 B.xxx.net 反向代理到C（域名不关心）

C set cookie SESSIONID in B.xxx.net （应用程序Cookie） same-site:none

B set cookie USER in xxx.net　　　　（SSO cookie） same-site:none

A iframe B，request header有USER和SESSIONID两个cookie

这里USER是否会在B请求时由于时一级域名下的自动带上不得而知，但也不关心;因为当删除C的cookie时，程序失败，证明C的cookie仍然起控制作用，并不是通过B植入一级域名的cookie USER 找到B内存内对应C的cookie，所以B的USER是否带上可不关心，因为浏览器里的C的处于B.xxx.net下的cookie起控制作用，这里只关心C的cookie SESSIONID 为什么iframe请求时带上了

那么如果把B和C的cookie设置为 Strict时，应当导致程序失败，但结果并没有，跟踪request，发现B和C的Cookie均仍在ajax时被传输，与预期不符

2 site vs origin

https://blog.csdn.net/azl397985856/article/details/107054007/

Origin 是协议(例如 HTTP 或 HTTPS )、主机名和端口的组合。例如，给定一个 URL https://www.example.com:443/foo，它的 Origin 就是 https://www.example.com:443。

具有相同协议，主机名和端口的组合的网站被视为 相同来源 。其他所有内容均视为 跨域

在上面的示例中， site 是 TLD 和它前面的部分域的组合。例如，给定一个URL https://www.example.com:443/foo ，site 就是 example.com 。

所以A与B都在一级域名xxx.net下，无论same-site为none还是strict，ifram时都会允许带上cookie，因为它们是同站的

3 做一个案例测试

写一个http://localhost:8082作为A'

嵌入网关B.xxx.net

为了测试，开启Fiddler edit response的两个头Content-Security-Policy X-Frame-Options

ps：

X-Frame-Options	Content-Security-Policy	表现
SAMEORIGIN	有值但没有http://localhost:8082/	because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'
无	有值但没有http://localhost:8082/	because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'
SAMEORIGIN	无	in a frame because it set 'X-Frame-Options' to 'sameorigin'
SAMEORIGIN	set frame-ancestors http://localhost:8082/	ok
无	set frame-ancestors http://localhost:8082/	ok
无	无	ok

此时页面正常显示，即使跨域（协议http vs https，host，端口）由于Same-ste设置为空了 iframe内ajax post仍然会携带，与预期相符

然后将 B的cookie - USER in xxx.net 和 C的cookie - SESSIONISD in B.xxx.net 的same-site改为Strict，触发iframe内ajax post请求

结果显示 request没有带 USER 和 SESSIONID，请求失败，即使USER在B.xxx.net的一级域名xxx.net下也没带

4 有几个网站

A.xxx.net

D.yyy.net

B.xxx.net -> 反向代理 C

A与D 嵌入B均能够正常使用，但原因是不同的：

A的地址与B地址同属于xxx.net一级域名下，无论B与C的cookie怎么设置，都会携带cookie

D的一级域名yyy.net 与B一级域名不同，目前因为B和C的cookie same-site均不设值，故能工作；如果将来B与C应整体安全要求升级Cookie安全等级，则D iframe内B请求均会无登录态；

暂时没发现http协议对跨站或跨域iframe及ajax请求Cookie携带有白名单规则

<!DOCTYPE HTML>
 
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Iframe Application</title>
    <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
</head>
<body>
below iframes
<iframe width="1200px" height="800px" src="https://B.xxx.net/index.html"></iframe>
</body>
</html>