安全与隐私benhoyt.com编辑精选
不要试图净化输入——应转义输出
Don’t try to sanitize input – escape output
2020 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章主张一个反直觉的安全原则：不要试图“净化”用户输入，而应在输出时根据目标上下文（HTML、SQL、URL 等）进行转义。作者认为在输入端清洗数据会破坏原始信息，而输出转义才是防止 XSS 和注入攻击的正确位置。文章多次登上 HN 首页，评论区也围绕“输入净化 vs 输出转义”展开了激烈争论。
为什么经久不衰：它挑战了很多人凭直觉遵循的安全教条，而框架默认转义、参数化查询普及的今天，理解这条原则背后的逻辑仍然能帮你避开注入类漏洞。
HN 评论精选
实践者经验：入口和出口都应处理，输出过滤便于集中修复
两者都应该做。在入口做基本的 SQL 净化以便安全存储，在出口再做一次完整处理以便安全展示。我们在 Reddit 就是这么做的：入口做基本 SQL 净化，返回给用户前再全面处理一遍。这样做的好处是，当有人发现绕过净化方法的新手段时，我们只需更新输出过滤器，一切就自动安全了，不必全库扫描修复坏数据。（编辑：我说的“净化输入”其实指参数化查询，用泛指的说法是因为不只针对 SQL。）
jedberg查看英文原文
You should do both. Sanitize your inputs so that it can be safely stored in your data store, and then sanitize your output so it can be safely displayed. We did this at reddit. We had basic SQL sanitization on the way in, and then a full pass on the way back to the user. The advantage this gave us is that when someone discovered a new way to hack our sanitization, all we had to do was update the output filter and everything was magically safe. We didn't have to do full database scans to find all the bad data and change it. Edit: Apparently I shouldn't have simplified "paramaterazation of SQL" as "sanitize your input". I used the more generic term since I was talking about any kind of data store. But yes, it was of course parameterized.
反对：把危险数据存库等于给未来的维护者埋地雷
所以他的意思是：1) 接受用户提交的危险内容并原样存进数据库；2) 确保代码中每一处读取该数据的地方都正确处理；3) 确保现在和未来的每个程序员在所有读取并展示用户数据的地方都记得这么做。这主意太糟了。别给代码的其他维护者埋地雷——那个维护者可能就是六个月后的你自己。输入要净化，输出也要转义。
rossdavidh查看英文原文
So, essentially he is saying: 1) go ahead and accept the risky thing from your users, and store it right there in your database, but 2) make sure that you remember, in every single place in your code where you read that out of the database, to treat it properly, and 3) make sure that every other programmer, now or at any time in the future, remembers to do this also, in any code they write which reads user input out of the database and puts it on the screen. What a bad idea. Don't leave landmines there for other maintainers of the code to step on. Especially because the other maintainer may actually be you, six months or a year from now. Sanitize your inputs. Also, escape your outputs.
用“规范化+按输出上下文转义”的框架来理解这个问题更清晰
更好的思考方式是规范化。应用内部应确定一种唯一的数据表示方式。输入时你的工作是验证和编码：比如把 Windows-1252 转成 UTF-8，无效码点则剔除或报错。输出时根据目标设备转义：进 HTML 就 HTML 转义，进 URL 就 URL 编码，进 SQL 就 SQL 转义，进 CSV 就加引号。这样应用内部逻辑保持简单（格式转换只发生在系统边界），也更灵活。
nostrademons查看英文原文
I think a better way to think of this may be in terms of canonicalization. Inside your application, you should decide on a single canonical way to represent data, one which fits the type of processing and expected use of the application. For example, you might decide that all strings should be UTF8, and should be interpreted (and stored) as whatever the user initially wrote. You might decide that any structured data should be parsed and then stored as protobufs in a BigTable. Or you might decide that an RDBMS is your native datastore and use whatever the native string encoding is for it, as well as parse & normalize data into tables upon input. Then, whenever you take input, your job is to validate and encode it. If you get a Windows-1252 string, you should re-encode it to utf8 for further storage. If it has data that are invalid UTF-8 codepoints, you should either strip, replace with a replacement character, or notify the user with a validation failure. Same with structured data that fails your normalization rules - you should usually notify the user. And when you send output, you should escape based on the intended output device. If you're putting it in an HTML page, HTML-escape it. If it's a URL, url-encode it. If it's a database query, SQL escape it. If it's a CSV, quote it. Thinking in these terms keeps the internal logic of your application simple (there are no format conversions except at system boundaries), and it also gives you a lot of flexibility to preserve the user's intent and add new output formats later.
针对文中“解析 SQL 白名单”的建议，提出只读账户+视图更稳妥
如果你真要允许用户输入任意 SQL 查询，应该使用一个只能访问相关数据的只读用户；需要隐藏列就用视图。试图解析 SQL 很容易出大问题，尤其是有人利用你数据库的边界情况时。
Sebb767查看英文原文
> The parallel for SQL injection might be if you’re building a data charting tool that allows users to enter arbitrary SQL queries. You might want to allow them to enter SELECT queries but not data-modification queries. In these cases you’re best off using a proper SQL parser [...] to ensure it’s a well-formed SELECT query – but doing this correctly is not trivial, so be sure to get security review. If you are ever in this situation, you should actually use a dedicated read-only user that can only access the relevant data. If you need to hide columns, use views. Trying to parse SQL can easily go very wrong, especially when someone (ab-)uses the edge cases of your DB.
历次讨论
同类还值得读
非法素数
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编辑精选