一个空格就能让服务器宕机，未对你信吗？输入2019年，某知名电商平台的做过搜索框就栽在这上面。用户输入一个带前导空格的滤造漏洞商品名，后端直接把字符串丢进SQL查询，未对结果数据库报错，输入整条商品列表接口瘫痪了四十分钟。做过事后排查发现，滤造漏洞攻击者只是未对利用空格绕过了关键字过滤——因为开发只拦了`' OR 1=1`，压根没trim输入。输入

这类漏洞的做过本质，是滤造漏洞信任了不该信任的东西。用户输入是未对洪水，你得修堤坝，输入而不是做过祈祷洪水别来。但很多程序员写代码时，脑子里默认“用户都是好人”，参数传进来就直接拼SQL、拼HTML、拼命令行。等到出事才拍大腿——可数据已经泄露了，或者服务器已经被人拿下了。

举几个扎心的例子。评论区里有人贴了段JavaScript，尖括号没转义，结果每个访客浏览器都弹出一个伪造的登录框，密码全被收割。这招叫存储型XSS，比钓鱼网站还阴险——用户以为自己在跟正规网站对话，其实脚本早把键盘记录传走了。还有更蠢的，某个后台管理页面用`system("ping " . $_GET['ip'])`做连通性测试，攻击者填`127.0.0.1; cat /etc/passwd`，服务器上的敏感文件直接裸奔。

你可能会说，这些老掉牙的漏洞，现在框架都自动防护了。没错，但框架只能挡住已知套路。哪天业务需要拼接动态规则，或者某个第三方库没跟上补丁，缝隙就出来了。我见过一个团队，用参数化查询防住了SQL注入，却在导出Excel时把用户输入当文件名——结果路径穿越漏洞，能下载服务器上任意文件。这就像你给前门上了三道锁，后门却敞开着。

过滤不是可有可无的装饰，而是安全的第一道防线。具体怎么做？输入校验必须白名单优先，比如只允许字母数字，长度限制死，格式用正则卡死。别用黑名单——你永远猜不全攻击者的花招。其次是编码输出，HTML实体编码、URL编码、SQL转义，各管各的战场。最后，永远别把用户输入直接拼进命令或查询，用参数化接口，或者至少用`escapeShellArg()`这类函数。

有个反直觉的事实：过滤过度同样危险。某论坛曾把所有`<`字符都删掉，结果用户发不了数学公式，连`a`写成`%3Cscript%3E`，如果后端只做一次解码，照样中招。所以过滤要讲平衡，既要拦恶意载荷，又要保留合法功能。这需要你理解数据会经过哪些处理环节，每个环节该用什么策略。

写代码的时候，把“用户输入”四个字刻在脑子里。每次拿到外部数据，先问自己：这东西会被拼到哪里？数据库？HTML？Shell命令？还是文件路径？每个目的地都有对应的防护手段。别偷懒，别觉得“应该没人这么干”。我见过一个内部系统，开发以为只有公司员工能访问，结果被搜索引擎爬虫抓到了登录页，攻击者用弱口令爆破进去，把整个客户数据库拖走了。用户输入不可信，这是铁律——哪怕来源是内部网络。

最后说个实操技巧：写个统一的输入过滤函数，全局调用。别在每处代码各自为政，那样迟早漏掉某个角落。用现成的安全库，比如OWASP的ESAPI，或者语言自带的过滤器。但记住，过滤只是缓解措施，不是万能药。真正的安全需要多层防御——输入校验、输出编码、最小权限、日志审计，缺一不可。你要是只做一层，那就等于把鸡蛋全放在一个篮子里，篮子一破，全完蛋。