章节主旨
本章讲用 80/20 的性价比思路给 Claude Code 及其产出的应用做安全加固:识别几类最常见的低垂果实(对话日志泄漏密钥、包名幻觉引发的供应链攻击、数据库未开 RLS、公网服务被扫描、信用卡数据落地),用极小的配置改动挡掉约 90% 的攻击面,最后用一段安全审计 prompt 收尾。
核心论点
- 安全是相对的,只需做到 80/20——万物皆可黑,目标不是绝对安全,而是让攻破成本高于你的资产价值。(→ 详解1)
- 和 Claude 明文聊天会持续泄漏密钥——所有对话存在
~/.claude的 JSONL 日志里,粘过的 API key 都在其中;把密钥收敛进.env、别进 Git 是第一低垂果实。(→ 详解2) - AI 会幻觉包名,催生 typosquatting 供应链攻击——攻击者预先注册拼写相近的恶意包,你该审计依赖清单。(→ 详解3)
- 数据库开一个 RLS 开关挡掉九成泄露——Supabase 默认不开,不开则任一用户的公钥能读写删全表。(→ 详解4)
- 任何公网暴露面都会被机器人农场持续扫描——URL 一上公网就被扫端口找漏洞;别把极敏感数据(尤其信用卡)交给这类服务。(→ 详解5)
- 公网项目收尾跑一遍安全审计,且用无偏见的新 agent——审计与实现要换独立会话甚至换模型,避免同一 agent 自我美化。(→ 详解6)
知识点详解
1. 80/20 安全观:让攻破成本高于资产价值 2:40:32
安全讨论常分裂成两个极端:一端是把 DNA、密码全塞给 AI 的「加速主义者」,一端是「一切都该在裸机上跑」的老派。Nick 的立场是中间——务实。
是什么:万物皆可黑,连国防部都可黑,区别只在「多难黑」。所以别追求绝对安全,而是 80/20 地清掉大部分低垂果实,接受总有一小撮人会试图攻破。
为什么:攻击面随你的应用规模一比一增长。Nick 举例自己早年 YouTube 每月一次登录尝试(还都是本人),如今每天 30-40 次有人试图爆破。资产越大、越公众,越会被盯上。
怎么用:把设置加固到「攻破所需的时间精力,超过其中资产的价值」即可——相当于给房子装个栅栏和摄像头,挡掉顺手作案者,而非造铜墙铁壁。
2. 对话日志泄漏密钥:密钥收敛进 .env 2:42:27
是什么:与 Claude 明文对话时,你其实每次都在泄漏 API key。所有 Claude Code 对话被完整存进 ~/.claude(home 目录下的隐藏文件夹)里的 JSONL 日志——逐行 JSON,原样记录 user/assistant 每一句。
演示要点:Nick 让一个 agent 搜索该目录下含某关键词的历史,瞬间逐行拉出完整旧对话。这意味着你历次粘贴的密钥都以明文躺在那里。
为什么危险:同一个密钥散落在 5 个地方,被撞见的概率不是高 5 倍,而是高约 500 倍。对话历史正是攻击者和例行数据检查会翻的地方。
怎么用:把所有 API key 收进 环境变量文件 是最简单收敛手段。并叮嘱 Claude「永不读取或显示 .env 内容」;同时别把含密钥的文件推上 GitHub——一旦推送就等于挂到了公网,更糟。演示中他把动物名存进伪 .env 后,agent 遍历全目录也搜不出该名字,印证了收敛的效果。
3. 包名幻觉与 typosquatting 供应链攻击 2:47:07
是什么:AI 模型常幻觉出不存在的包名。启动新项目时,AI 会通过 npm 等包管理器自动装它「以为需要」的依赖;但由于 token 编码方式,Claude 有时会把 acorn 写成 acorns 或带多余字母的变体。
攻击原理:攻击者早已利用这种统计规律,预先注册这些拼写相近的包(域名/包名仿冒),包内藏恶意代码——典型 payload 就是「遍历受害者 ~/.claude 对话日志并回传给我」,近似一种 提示注入。
为什么危险:一旦你的项目挂着可无限用量的 API key,被劫持后可能被刷出数万美元账单。
怎么用:审计依赖清单里的陌生包。可直接问 Claude:「实例化前先检查 npm 安装列表,确认都是有可验证历史、非恶意的正规包。」
4. 数据库 RLS:一个开关挡掉九成泄露 2:50:43
适用对象:做全栈应用或需外部数据存储的人。(Nick 自己现多用本地 JSON 文件,因主要做个人/团队内部流程,不做端到端全栈。)
是什么:行级安全 Row Level Security 是最简单有效的一道防线,能挡掉约 90% 的数据库泄露,却几乎没人开。Supabase 默认不开 RLS。
为什么危险:不开 RLS 时,用户注册拿到的公钥能读、写、删数据库里其他所有行。
反面案例:曾有个号称「agent 版 Facebook」的产品 Moltbook,一次基础安全审计发现其数据库没开 RLS——审计者几秒读遍平台上所有 AI agent,又靠写权限造了约 10 万个假档案。讽刺的是 Meta 后来收购了它,买到的档案里很大一块是假的。开 RLS 只需两秒,是极典型的低垂果实。
5. 公网暴露面被持续扫描,敏感数据与信用卡不落地 2:52:30
是什么:任何短小 URL、跑在 VPS(如 Hostinger)IP 段上的公网服务(如 OpenClaw),都会被机器人农场持续查询。这些农场每秒发数万请求,扫遍每个开放端口找漏洞,一旦命中一处就能拿到整台机器的控制权。
怎么用:凡对外暴露,就别放极端敏感的东西——别把社保号、护照照片交给公网 agent。相较之下,本地运行、经 Telegram 等受信连接器认证的 Claude 实例被黑概率低得多,因为它不直接开放对外端口。
信用卡红线 2:54:36:永远别碰信用卡号。别存、别读——一旦被 AI agent 读到,就会像密钥一样进对话历史,日后误配置、推 Git 或转手电脑都会明文泄漏。攻击者会正则扫全盘找 16-20 位连号再比对 Visa 模式。做支付就交给 Stripe 这类 PCI 合规 服务,把合规与存储风险外包出去。
6. 收尾跑安全审计,且用无偏见的新 agent 2:56:07
是什么:项目做完后,把任何对外暴露面丢进一段安全审计 prompt 跑一遍,覆盖剩下的 80/20。这段 prompt 是 Nick 读了大量安全博客后、连同 AI agent 一起打磨出来的,会自上而下列出所有安全问题(如硬编码密钥、.gitignore 未含 .env、供应链低知名度包等),并标注「不适用/失败」。
无偏审计 2:57:28:关键在于开一个全新会话来跑审计,不带任何开发时的上下文——否则开发它的 agent 会自我美化、倾向认为自己写得更好而漏判。
怎么用:审计发现问题后,再另起一个 agent 去实现修复——实现 agent 也不该被审计的「过度约束」语气带偏。可用 子 agent 或换 Codex、Gemini 等其他模型执行,最后交给 Claude 复核。这与「7 分下注 Claude、3 分分散到其他模型」的模型分散同理:通过跨模型分散,对冲 Claude 自身的固有偏差,理想方案是让多模型各跑一遍。
术语
- 80/20 security(80/20 安全):只清最划算的低垂果实,把攻破成本抬到高于资产价值,接受残余风险
- attack surface(攻击面):系统可被攻击的入口总和,随应用规模与曝光度一比一增长
- JSONL log(JSONL 日志):
~/.claude下逐行 JSON 存储的完整对话历史,含明文密钥 - typosquatting(仿冒抢注):注册与正规包/域名拼写相近的名字投放恶意内容
- RLS / Row Level Security(行级安全):数据库按行控制读写权限的开关,Supabase 默认不开
- PCI compliant(PCI 合规):支付卡行业数据安全标准,Stripe 等服务代为承担
自检问题
- 为什么「和 Claude 明文聊天会泄漏密钥」?该怎么办?
答案:所有对话被存进
~/.claude的 JSONL 日志,历次粘贴的 API key 以明文躺在其中;同一密钥散落越多被撞见概率越高(约 500 倍)。对策是把密钥收敛进.env、叮嘱 AI 永不读取显示、且别推上 GitHub。见详解2 2:42:27 - 「包名幻觉」如何演变成实际攻击? 答案:AI 常把包名写成拼写相近的变体(acorn→acorns);攻击者预先注册这些仿冒包(typosquatting)并植入恶意代码,典型 payload 是遍历回传你的对话日志,近似提示注入。对策:审计依赖清单里的陌生包。见详解3 2:47:07
- 为什么跑安全审计要「另起一个全新会话」,甚至换模型? 答案:开发该项目的 agent 带着上下文会自我美化、倾向认为自己写得对而漏判;新会话无偏见。实现修复也另起 agent,并可跨 Codex/Gemini/Claude 分散,对冲单模型的固有偏差。见详解6 2:57:28
- Nick 主张的整体安全观是什么? 答案:80/20——万物皆可黑,只需把攻破成本抬到高于你的资产价值,清掉低垂果实(密钥收敛、审计依赖、开 RLS、公网不放敏感数据、跑审计),接受残余小概率风险。见详解1 2:40:32