Google 如何做到这一点? +1 小部件脱离了 iframe?

发布于 2024-12-03 02:29:25 字数 455 浏览 1 评论 0原文

不知何故,将鼠标悬停在 Google+ 加一小部件上可以引入工具提示类型的交易,该交易明显大于包含它的 元素。我检查了 DOM 来确认这一点。*

iframe 边界

那么:

  1. 什么?怎么办!?

  2. 如果被恶意使用,这不是一个巨大的点击劫持机会吗? (想象一下有人对这些社交小部件进行中间人攻击!)

*更新:我看到的是工具提示 y 消息在一秒钟内动态创建的 iframe .

Somehow, hovering over a Google+ plus-one widget can introduce a tooltip-type deal that is clearly larger than the <iframe> element in which it is contained. I’ve inspected the DOM to confirm this.*

iframe boundaries

So:

  1. What? How!?

  2. Is this not a massive opportunity for clickjacking, if used maliciously? (Imagine someone doing a MITM for these social widgets!)

*Update: What I saw was that the tooltip-y message was in a second, dynamically created iframe.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

花海 2024-12-10 02:29:25

Google +1 小部件是在您的网站上运行的 JavaScript,它正在构建 iframe。此 JavaScript 小部件在您网站的上下文中运行,因此不受 的约束iframe 的原始继承规则。因此,这个 JavaScript 小部件可以在父站点上设置它想要的任何 DOM 事件,即使它看起来只是一个简单的 iframe

另一件事是,为什么 Google 使用 iframe?为什么不在页面上生成一个 div 呢?因为链接源自 iframe,所以可以在请求中嵌入 CSRF(跨站点请求伪造)令牌,并且父站点无法读取此令牌并伪造请求。因此,iframe 是一种反 CSRF 措施,它依赖于源继承规则来保护自身免受恶意父级的侵害。

从攻击的角度来看,这更像是 XSS(跨站点脚本)而不是 UI-Redress。您向 Google 授予对您网站的访问权限,他们可以劫持您用户的 cookie 或对您的网站执行 XmlHttpRequests(如果他们愿意的话)(但人们会起诉他们恶意且富有)。

在这种情况下,你必须信任谷歌,但谷歌不信任你。

有一些方法可以减轻这些网络错误对隐私的影响

The Google +1 widget is JavaScript that runs on your website that is building an iframe. This JavaScript widget is running within the context of your website and therefore is not constrained by the Origin Inheritance Rules for iframes. Therefore this JavaScript widget can set whatever DOM events it wants on the parent site even though it appears to be just a simple iframe.

Another thing, why is Google using an iframe? Why not just generate a div on the page? Well because the link originates from the iframe, a CSRF (cross-site request forgery) token can be embedded in the request and the parent site cannot read this token and forge the request. So the iframe is an anti-CSRF measure that relies upon the Origin Inheritance rules to protect itself from a malicious parent.

From an attack perspective this is more like XSS (cross-site scripting) than UI-Redress. You are giving Google access to your website and they could hijack your users' cookie's or perform XmlHttpRequests against your website if they so choose (but then people would sue them for being malicious and wealthy).

In this situation you HAVE to trust Google, but Google doesn't trust you.

There are ways of mitigating the privacy impact of these web-bugs.

全部不再 2024-12-10 02:29:25

Google 使用 iFrame 来防止“标准 DIV 泄漏”。他们的闭包库对话框做了同样的事情。这可能只是为了防止其他内容渗入 +1 按钮。 http://closure-library.googlecode.com/svn /trunk/closure/goog/demos/dialog.html

Google uses iFrames to prevent "leaky standard DIVs." Their closure library dialog does the same thing. It is probably just so that other content cannot bleed into the +1 button. http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/dialog.html.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文