```html

不合法的网络案例

去年秋天，我帮一个做电商的网络朋友处理服务器日志。他卖定制手机壳，案例小本生意，不合结果连续三天收到 Stripe 的网络风控警告。我翻日志发现，案例有个 IP 在凌晨两点到四点之间，不合用脚本批量生成订单，网络每笔金额都是案例 0.99 美元，收货地址全填同一个俄勒冈州的不合仓库。

这不是网络普通刷单。对方在测试他的案例支付网关有没有 amount 字段的整数溢出漏洞——把 0.99 改成 0.99 后面加一堆 9，或者用负数金额。不合Stripe 拦住了，网络但朋友自己写的案例订单校验逻辑没拦住。有个订单金额变成了 -0.99，系统反而给他账户打了 0.99 美元。虽然钱不多，但漏洞是真的。

这还算低级的。更麻烦的是 SSRF。我另一个做安全的朋友，在给某政务云做渗透测试时，发现一个文件下载接口：/api/download?url=http://internal-server/secret.pdf。他把 url 改成 http://169.254.169.254/latest/meta-data/，直接拿到了云服务器的临时凭证。这个案例后来被写进了他们内部培训材料，但对外只字不提——因为那个政务云还在用。

SSRF 的可怕之处在于，它不需要你写恶意代码，只是“借用”了服务器的信任关系。服务器以为自己在访问一个普通网址，实际上是在帮攻击者探测内网。我见过最离谱的一个，是某银行 App 的“分享到微信”功能。分享链接里有个 redirect_uri 参数，没做白名单校验。攻击者改成 http://10.0.0.1/admin，服务器就乖乖去请求了内网管理后台。虽然返回内容没直接显示给用户，但通过响应时间差异，攻击者能判断内网哪些端口是开放的。

这些案例有个共同点：漏洞不在高深的技术里，而在“以为不会有人这么干”的假设里。开发人员觉得参数是前端传的，肯定合法；觉得 URL 是自家 App 生成的，肯定安全；觉得用户 ID 是数据库自增的，猜不到。但攻击者恰恰就干这些“不可能”的事。

我自己的博客也中过招。有次图省事，用 eval() 解析一个 JSON 配置。结果有人提交了 { "name": "__import__('os').system('rm -rf /tmp/test')"}。还好只是测试环境，只删了个临时目录。从那以后，我所有涉及用户输入的地方，都老老实实用 json.loads() 或者 ast.literal_eval()。麻烦是麻烦，但比半夜被叫起来修服务器强。

写这些不是要吓唬谁。网络攻击早就不是电影里那种黑屏绿字的炫技了。更多时候，它就是一段普通的 HTTP 请求，一个没过滤的参数，一次没校验的跳转。你不需要成为安全专家，但至少得知道：用户输入永远不可信，内网请求也要当外网防。剩下的，交给日志和告警。我那个电商朋友后来加了条规则——任何金额为负数的订单，直接封 IP 加人工审核。简单，但管用。