安全与隐私blog.innerht.ml
Google YOLO 点击劫持
Google YOLO clickjacking
2018 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者演示了如何利用 Google YOLO（一键登录组件）的点击劫持漏洞，在用户不知情点击的情况下获取其 Google 账号的姓名、头像和邮箱地址。Google 收到漏洞报告后以“登录组件必须可被 iframe 嵌入才能工作”为由拒绝将其列为安全漏洞，随后只是悄悄禁止了作者域名的 API 访问。
为什么经久不衰：它揭示了嵌入式登录组件与点击劫持结合的隐私风险，以及大厂对这类“非传统”漏洞的处置态度，至今仍是 Web 安全的经典案例。
HN 评论精选
Google 拒绝将点击劫持列为安全漏洞，暴露了登录组件的固有风险
利用 Google YOLO 的点击劫持可以泄露访客的姓名、头像和邮箱地址——没错，我甚至能知道你的邮箱。Google 对漏洞报告的回复是：经调查决定不将其列为安全漏洞，登录组件必须可被 iframe 嵌入才能工作，也不确定如何修复。这就是我们不信任登录组件的原因吧？
mirimir查看英文原文
Google cache: https://webcache.googleusercontent.com/search?q=cache:kv9fSsl32yEJ:https://blog.innerht.ml/google-yolo/+&cd=1&hl=en&ct=clnk&gl=ae&client=firefox-b > Exploiting Clickjacking on Google YOLO allows visitors' name, profile picture and email address to be leaked. That's right, I can even know your email address. :). Click here if you want to see behind the sense (make sure you have logged in Google with a modern browser, PC preferably). Google's reply to a VRP submission: > Thanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug. > The login widget has to be frameable for it to work. I'm not sure how we could fix this to prevent this problem, but thanks for the report! That's why we don't trust login widgets, right?
作者用 Cookie 同意按钮做诱饵，讽刺用户对此类按钮已形成无意识点击习惯
还记得你一开始点的那个 Cookie 同意按钮吗？那其实就是一次点击劫持尝试。太狠了。我现在对 Cookie 同意按钮已经完全进入自动驾驶模式了，很好奇有多少人跟我一样。这是个非常聪明的点击劫持位置。
etxm查看英文原文
> Remember the cookie consent button you clicked at the very beginning? That's right, it was a Clickjacking attempt :) Brutal. I have gone 100% autopilot to “cookie consent buttons”. I’m curious how many people are. That’s a very clever place to click jack.
浏览器 UI（如标签页关闭按钮）比页面内元素更难被劫持，可作为更可信的交互目标
概括地说，很难判断网页上哪些像素是可信合法的。比如每次看到“确定要离开此页面吗”的弹窗，我都会犹豫一下它是不是伪造的。Chrome 的这个弹窗是模态的，无法点击标签页的关闭按钮绕过；而 Firefox 允许你点标签页的 [x] 或按 Ctrl+F4 关闭。任何 CSS 和 JS 组合都几乎不可能“逃出”浏览器窗口去劫持标签页的关闭按钮，所以点那里感觉更安全。
jasode查看英文原文
To generalize, it's not easy to judge what pixels on a browser's rendered webpage are trustworthy and legitimate. For example, every time I see a "Are you sure you want to leave this page?"[1], I hesitate for a moment and wonder if that dialog box is being spoofed. That dialog shows up for many scammy websites but also legitimate ones too. Yes, one could try to learn which dialogs can't be spoofed[2] but there's always paranoia because you can't keep up-to-date with all unknown future exploits. Chrome makes that dialog box scarier because it is modal and you can't click outside of the box on the browser's tab [x] to close the window. (You also can't use the keyboard Ctrl+F4 to close it either.) In contrast, Firefox let's you avoid clicking the dialog box by letting you click on the tab's [x] or press Ctrl+F4. It's easy to replicate these differences in behavior on website regex101.com.[3] Type a few characters there and then try to navigate away from the page. Chrome forces you to interact with the dialog box but Firefox lets you click [x] on the browser tab. It's nearly impossible for any combination of CSS and Javascript to "escape" the browser window and hijack the [x] button on the browser's tab so it feels "safer" just to click there. [1] https://www.google.com/search?q=google+chrome+%22are+you+sure+you+want+to+leave%22&source=lnms&tbm=isch [2] https://superuser.com/questions/639084/malicious-confirm-navigation-dialogs [3] https://regex101.com/
Google 的修复方式是悄悄封禁作者域名，而非真正修复漏洞
文章发布后不久，Google 悄悄禁止了我的域名使用该 API：客户端来源不被允许使用此 API。于是一些按钮失效了，现在你只能相信博客所说的一切都是真的。好吧，确实是。而 Google 的“缓解措施”只是阻止对该 API 的访问，这让事情变得更有意思了。
woliveirajr查看英文原文
> Shortly after thie article was published, Google silently prevented my domain from using the API: > The client origin is not permitted to use this API. > Welp. So some buttons stoped working, and now you have to believe that everything was as the blog said. Well, it was. And a "mitigation" from google being just avoiding the access to the API just makes things more interesting.
历次讨论
同类还值得读
非法素数
Illegal prime
维基百科条目，介绍“非法素数”：某些素数之所以被称为“非法”，是因为它们经特定编码后，恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码，有人把…
安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选关于 /dev/urandom 的常见误区
Myths about /dev/urandom
（Thomas Hühn 撰写，2014 年首发并持续更新）逐条反驳关于 /dev/urandom 的常见误解：它与 /dev/random 使用的是同一个 CSPRNG，一旦完…
安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选AES 高级加密标准火柴人图解
A Stick Figure Guide to the Advanced Encryption Standard (AES)
一篇用火柴人漫画形式讲解 AES（高级加密标准）算法的经典科普文章。
安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选指纹是用户名，不是密码
Fingerprints are Usernames, not Passwords
作者（eCryptfs 维护者、Ubuntu 安全工程师）认为指纹等生物特征是公开、不可更改的标识，应视作用户名而非密码，不能当作秘密凭据用于认证。
安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.comHTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。
安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选