安全与隐私behind-the-enemy-lines.com
我如何利用 Google 攻击自己，并把带宽账单推到 1000 美元
How I attacked myself using Google and I ramped up a $1000 bandwidth bill
2012 — 2015，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者讲述自己如何用 Google 意外“攻击”了自己：他在 Google Spreadsheet 中嵌入了指向自己服务器的图片，结果 Google 每小时都重新抓取这些资源，导致他的服务器被持续请求，最终产生了约 1000 美元的 AWS 带宽账单。文章记录了排查过程，以及 Amazon 最终退还了这笔意外费用。
为什么经久不衰：一次真实又离奇的“自伤式 DDoS”事故，揭示了第三方平台热链接与云端计费叠加的隐性风险，对今天依赖云服务和嵌入资源的开发者仍有警示意义。
HN 评论精选
批评 Google Spreadsheet 每小时强制重新抓取嵌入资源的设计，认为这实质上是一种易用的 DDoS 机制。
给 Amazon 点赞，慷慨地退还了超额费用；给 Google 差评，它让任何人都能轻松发起覆盖全网的 DDoS 攻击，是对内容提供商最大的威胁。想想以后越来越多的 Google Spreadsheet 用户热链接图片、音频、视频，内容提供商要承担多少额外成本。每小时整点重新下载资源、无论表格是否打开，这绝对是糟糕的设计决策。
OzzyB查看英文原文
+1 For Amazon for kindly reimbursing the overage charge. -1 For Google for creating what is the biggest threat to content providers by enabling easy-to-use DDOS attacks across the entire interwebs. </hyperbole> Seriously, is this what we have to look forward to when Google Spreadsheets, and God knows what else, become ever-more popular? Think about all the additional onerus costs that would be incurred by content providers as more and more Google Spreadsheet users hotlink images, mp3s, videos... This has to be a bad design decision by Google, there's no need to redownload assets by-the-hour, on-the-hour, regardless of whether the user's spreadsheet is open or not. Is it time to go back to the days of putting your web assets behind $HTTP_REFERER?
质疑 Google 每小时重新抓取的技术原因，认为通过缓存和条件请求本可避免。
但为什么要每小时重新下载？是表格在浏览器里被动打开就会触发，还是有其他进程每小时重新加载表格？如果是前者，我不会轻易原谅 Google——即使出于隐私考虑不缓存，合理的 URL 设计和条件请求也应该能避免这种整点自动全量下载。
gojomo查看英文原文
But, why re-downloading every hour? Does merely having the spreadsheet passively open in a browser trigger that, or was some other process re-loading the spreadsheet every hour? (If the former, I wouldn't be as forgiving of Google. I understand the desire not to cache possibly-private data, but proper URL design and conditional GETs should be able to prevent the entire download on an automatic hourly schedule. And even if the latter – the author had chosen to reload the spreadsheet each hour – I'd want Google's design to allow browser-side caching to work for such embedded and/or generated images.)
称赞 Amazon 慷慨退还了本可拒绝的意外账单。
Amazon 能通情达理地退还这笔意外费用真的很棒。虽然严格来说责任在作者自己，他们本可以很刻薄地拒绝。
richardlblair查看英文原文
It's really awesome that Amazon was reasonable and refunded the charges because they were accidental. I mean, technically it was still your fault, so it would have been easy for them to be jerks about it.
认为文章精彩，戳中了开发者对 AWS 账单失控的普遍恐惧。
虽然这是转载，但我第一次错过了。这是一篇非常有趣、写得很好的文章，讲述了一个我们很多人都能共鸣的噩梦场景：莫名其妙暴涨的 AWS 账单。
thoman23查看英文原文
Apparently this is a repost, but I for one missed it the first time around. I'll just say I found it to be a highly entertaining and well-written account of a nightmare scenario I think many of us here can relate to: The unexpected and unexplained exploding AWS bill.
历次讨论
同类还值得读
非法素数
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编辑精选