搜索框是搜索个神奇的地方。你输入“手机”，型注它给你列出一排商品；你输入“admin”，搜索它可能就把后台的型注底裤掀给你看。这种事儿在SQL注入里有个专门的搜索名头——搜索型注入。它不像登录框那样直愣愣地让你交用户名密码，型注它藏得更深，搜索伪装成一次普通的型注查询。

原理其实不复杂。搜索开发者为了省事，型注经常把搜索功能写成这样：SELECT * FROM products WHERE name LIKE '%$keyword%'。搜索那个$keyword直接拼接进SQL语句，型注没过滤，搜索没转义。型注你输入的搜索每个字符都被数据库当成命令的一部分来解读。这就像你把一张写满字的纸条递给图书馆管理员，他看都不看就把纸条上的内容念给整个书架听。

我见过一个真实案例。某个电商站点的搜索框，输入“ %”会返回所有商品——因为LIKE '%%%'匹配了全部记录。这还算温和的。更狠的是有人输入%' UNION SELECT username, password FROM users-- ，搜索结果页直接把你登录名和密码哈希给渲染出来了。你猜怎么着？那个站点的密码还是MD5存的，连盐都没加。

搜索型注入最阴险的地方在于，它不报错。登录框注入失败会弹个“用户名或密码错误”，你至少知道撞了墙。搜索框不一样，你输入特殊字符，它可能返回空结果，也可能返回全部结果，甚至返回一堆看似无关的数据。这种模糊性让自动化扫描工具经常漏报，反倒是手工测试的人能靠直觉发现端倪——比如搜个单引号，页面空白了，或者搜个百分号，结果比预期多出几百条。

修复的办法倒是老生常谈：参数化查询，或者预编译语句。但现实里很多老项目改不动，一堆历史遗留代码像蜘蛛网一样缠在一起。有个朋友跟我抱怨过，他们的搜索功能接了三个不同的数据库，每个库的转义规则还不一样，改一处崩两处。最后他干脆写了个黑名单，把%、'、--、/*这些字符全给禁了。结果呢？用户搜“C++”搜不到，搜“100%纯棉”也搜不到，客服被骂了整整一周。

这事儿挺讽刺的。安全防护做过头，用户体验就完蛋；防护做不够，数据库就裸奔。平衡点在哪？我觉得得看业务场景。一个展示公开信息的博客站，搜索注入顶多让你多看几篇旧文章；但一个内部管理系统，搜索框连着员工工资表，那性质就完全变了。我见过最离谱的，有人把搜索框直接拼到了SELECT * FROM sys.tables后面，本来想搜个“客户名称”，结果把整个数据库的表结构全列出来了。

写代码的人总觉得自己不会犯这种低级错误，但疲劳加班的时候，谁没干过几件蠢事？搜索型注入的根子不在技术，在于“图省事”这个念头冒出来的那一瞬间。你少写的那几行参数化代码，总有一天会变成别人手里的万能钥匙。