iframe 引入第三方站点问题总结

肖恩分享
703 阅读5分钟

最近公司内容系统，需引入帆软第三方报表问题总结

1. # X-Frame-Options

报错：
6cd218a77c893c98e83b1b46de55a41.png X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 frame、iframe、embed 或者 object 中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面，从而避免点击劫持攻击。

  仅当访问文档的用户使用支持 X-Frame-Options 的浏览器时，此附加的安全性才会被提供。

语法 X-Frame-Options 有两个可能的值： X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN 3、指南 如果设置为 DENY，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为 SAMEORIGIN，那么页面就可以在同域名页面的 frame 中嵌套。

DENY

  表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。

SAMEORIGIN

  表示该页面可以在相同域名页面的 frame 中展示。规范让浏览器厂商决定此选项是否应用于顶层、父级或整个链，有人认为该选项不是很有用，除非所有的祖先页面都属于同一来源（origin）（见 bug 725490）。参见浏览器兼容性以获取详细的兼容性信息。

ALLOW-FROM uri Deprecated

  这是一个被弃用的指令，不再适用于现代浏览器，请不要使用它。在支持旧版浏览器时，页面可以在指定来源的 frame 中展示。请注意，在旧版 Firefox 上，它会遇到与 SAMEORIGIN 相同的问题——它不会检查 frame 所有的祖先页面来确定他们是否是同一来源。Content-Security-Policy HTTP 首部有一个 frame-ancestors 指令，你可以使用这一指令来代替。

配置 Nginx 配置 Nginx 发送 X-Frame-Options 响应头，把下面这行添加到 'http', 'server' 或者 'location' 的配置中：

add_header X-Frame-Options SAMEORIGIN always; nginx配置X-Frame-Options有四个参数:

1、DENY 表示该页面不允许在frame中展示，即便是在相同域名的页面中嵌套也不允许。 nginx配置示例：add_header X-Frame-Options DENY;

2、SAMEORIGIN 表示该页面可以在相同域名页面的frame中展示。 nginx配置示例：add_header X-Frame-Options SAMEORIGIN;

3、ALLOW-FROM url 表示该页面可以在指定来源的frame中展示。 nginx配置示例：add_header X-Frame-Options ‘ALLOW-FROM xxx.xxxxxx.com’; ‘’引号是必须要写的哦！

4、ALLOWALL 表示该页面允许全部来源域名的frame展示。 nginx配置示例：add_header X-Frame-Options ALLOWALL;

有时候我们需要允许多个url的来源，但是又不能全部开放，所以应该匹配第三种方法ALLOW-  FROM url，那么多个url该如何配置呢，百度了所有网站都没有找到，那么这里写给大家，其实很简单：
add_header X-Frame-Options ‘ALLOW-FROM  https://xxx.xxxxxx.com  https://xxx2.xxxxxxx.com’;
就是使用空格隔开就好了！

2. SameSite

处理这个问题的前提先熟悉 浏览器同源策略，Cookie的安全机制 当浏览器域名站点跟iframe 地址不一样时，浏览器会拒绝写入Cookie 默认情况下 SameSite 未设置，浏览器是不发送第三方 Cookie

SameSite

Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击和用户追踪。 Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

它可以设置三个值。

  • Strict
  • Lax
  • None

2.1 Strict
Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。

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

这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

2.2 Lax
Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。

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

导航到目标网址的 GET 请求，只包括三种情况：链接，预加载请求，GET 表单。详见下表
Lax请求设置了Strict或Lax以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。

2.3 None
Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。
下面的设置无效。

Set-Cookie: widget_session=abc123; SameSite=None

下面的设置有效。

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

Secure 与 SameSite 相关的标准最近发生了变化（MDN 记录了上面的新行为）。有关在特定浏览器版本中如何处理属性的信息，请参阅 cookie 浏览器兼容性表：

  • 如果 SameSite 未指定，则 SameSite=Lax 时新的默认值。以前，默认情况下会为有请求发送 cookie。
  • SameSite=None 的 cookie 还必须指定 Secure 属性（它们需要安全上下文）。
  • cookie 使用不同的方案（http: 或 https:）发送来自同一域的 cookie，则不再视为来自同一站点。

如何处理帆软报表问题

1.禁用浏览器samsite属性/或降低版本

2.保证同源策略cookie共享 (保证ip或域名一直)

修改本地hosts，使用nginx代码，配置本地域名跟帆软报表域名主站相同

3设置response.setHeader/“Set-Cookie”“HttpOnly;Secure;SameSite=None”)，需设置https证书 具体配置可以查看帆软官方处理方法

备注：SameSite 2021年9月，已经彻底移除可视化禁用和命令行禁用的方式， 例如

~~image.png 已不能使用

网友推荐谷歌插件，关闭本地谷歌SameSite策略

image.png

配置后并未好使，也可能本人配置错误

avatar
文章
阅读
粉丝