Google 如何做到这一点? +1 小部件脱离了 iframe?
不知何故,将鼠标悬停在 Google+ 加一小部件上可以引入工具提示类型的交易,该交易明显大于包含它的 元素。我检查了 DOM 来确认这一点。*
那么:
什么?怎么办!?
如果被恶意使用,这不是一个巨大的点击劫持机会吗? (想象一下有人对这些社交小部件进行中间人攻击!)
*更新:我看到的是工具提示 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.*
So:
What? How!?
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
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 simpleiframe
.Another thing, why is Google using an
iframe
? Why not just generate adiv
on the page? Well because the link originates from theiframe
, 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 theiframe
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.
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.