HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    安全与隐私blog.haschek.at

    用 Zip 炸弹防御网站

    Defending a website with Zip bombs

    3次上首页
    7年跨度
    809累计得分
    257条评论

    2017 — 2024,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这篇博客介绍如何用 zip 炸弹(gzip 压缩炸弹)来防御网站:面对恶意爬虫和漏洞扫描器的请求,服务器返回一个体积很小但解压后极其庞大的压缩响应,让抓取方在解压时耗尽内存或 CPU、甚至长时间挂起。文章来自 haschek.at 个人博客,2017 年发布后两度登上 Hacker News 首页,2024 年又被翻出来。

    为什么经久不衰:用极低的服务器成本让恶意爬虫自食其果,思路巧妙又实用;在爬虫和扫描器愈发泛滥的今天,依然值得一读。

    关键词 zip 炸弹反爬虫Web 安全gzip

    HN 评论精选

    建议用更底层的 Transfer-Encoding,并可叠加 XML 炸弹等多层手法,把攻击载荷压到极小。

    我觉得用 Transfer-Encoding 比 Content-Encoding 更好:它在协议栈更底层处理,而且必须被解码,而 Content-Encoding 通常只有客户端明确关心载荷内容时才会解。(这种情况下也不必声明巨大的 Content-Length,它由传输编码隐含。)还可以叠加 XML 炸弹,虽然那在协议栈更高层。当然可以把三种手法组合进一个载荷:先 gzip 一个 XML 炸弹再跟上 1GB 空格,然后再 gzip 一次、跟上 1GB 的 NUL,以 application/xml 配上两种编码发出去。补充:这种载荷的 100 GiB 版本压缩后在网络上只有约 160 KiB。(我不会分享它,因为这种「反向黑客」在法律上和分发恶意软件差不多。)

    colanderman查看英文原文

    I would think Transfer-Encoding would be a better choice than Content-Encoding. It's processed at a lower level of the stack and must be decoded – Content-Encoding is generally only decoded if the client is specifically interested in whatever's inside the payload. (Note that you don't have to specify the large Content-Length in this case as it is implied by the transfer coding.) Also worth trying is an XML bomb [1], though that's higher up the stack. Of course you can combine all three in one payload (since it's more likely that lower levels of the stack implement streaming processing): gzip an XML bomb followed by a gigabyte of space characters, then gzip that followed by a gigabyte of NULs, then serve it up as application/xml with both Content-Encoding and Transfer-Encoding: gzip. (Actually now that I think of it, even though a terabyte of NULs compresses to 1 GiB [2], I bet that file is itself highly compressible, or could be made to be if it's handcrafted. You could probably serve that up easily with a few MiB file using the above technique.) EDIT: In fact a 100 GiB version of such a payload compresses down do ~160 KiB on the wire. (No, I won't be sharing it as I'm pretty sure that such reverse-hacking is legally not much different than serving up malware, especially since black-hat crawlers are more likely than not running on compromised devices.) [1] https://en.wikipedia.org/wiki/Billion_laughs [2] https://superuser.com/questions/139253/what-is-the-maximum-compression-ratio-of-gzip/579290

    用慢速无限字节流让扫描机器人挂起,是同类反制思路的实战经验。

    这让我想起有次用 Node 写了个脚本,以缓慢稳定的节奏向那些扫描漏洞端点的机器人发送无尽的字节流。它们会一直挂着,没法继续下一个扫描任务,有些连接能保持好几周。我猜那些提前断掉的,是被维护者手动停了或者撞上了内存上限。美好时光。

    Scryptonite查看英文原文

    Reminds me of a time I once wrote a script in Node to send an endless stream of bytes at a slow & steady pace to bots that were scanning for vulnerable endpoints. It would cause them to hang, preventing them from continuing on to their next scanning job, some remaining connected for as long as weeks. I presume the ones that gave out sooner were manually stopped by whoever maintains them or they hit some sort of memory limit. Good times.

    补充了 Tor 隐藏服务被攻击的案例链接作为延伸阅读。

    有意思,相关阅读:一篇讲 Tor 隐藏服务遭攻击的文章(hackerfactor.com),以及它的后续篇。

    ruytlm查看英文原文

    Interesting and related re attacks on a Tor hidden service: http://www.hackerfactor.com/blog/index.php?/archives/762-Attacked-Over-Tor.html And the follow up: http://www.hackerfactor.com/blog/index.php?/archives/763-The-Continuing-Tor-Attack.html

    历次讨论

    同类还值得读

    1. 非法素数

      Illegal prime

      维基百科条目,介绍“非法素数”:某些素数之所以被称为“非法”,是因为它们经特定编码后,恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码,有人把…

      安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选
    2. 关于 /dev/urandom 的常见误区

      Myths about /dev/urandom

      (Thomas Hühn 撰写,2014 年首发并持续更新)逐条反驳关于 /dev/urandom 的常见误解:它与 /dev/random 使用的是同一个 CSPRNG,一旦完…

      安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选
    3. AES 高级加密标准火柴人图解

      A Stick Figure Guide to the Advanced Encryption Standard (AES)

      一篇用火柴人漫画形式讲解 AES(高级加密标准)算法的经典科普文章。

      安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选
    4. 指纹是用户名,不是密码

      Fingerprints are Usernames, not Passwords

      作者(eCryptfs 维护者、Ubuntu 安全工程师)认为指纹等生物特征是公开、不可更改的标识,应视作用户名而非密码,不能当作秘密凭据用于认证。

      安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.com
    5. HTTPS 连接的最初几毫秒(2009)

      The First Few Milliseconds of an HTTPS Connection (2009)

      逐毫秒拆解一次 HTTPS 连接建立时发生了什么,重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制,面向不熟悉该领域的读者。

      安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。