搜索框渗透

搜索框，搜索那个白色长条，框渗几乎是搜索互联网的入口。但很少有人把它当武器用。框渗我见过最狠的搜索一次渗透，不是框渗打数据库，而是搜索打搜索框本身。

那是框渗个老牌电商站，后台有个商品搜索功能，搜索看起来人畜无害。框渗测试时我随手输入一个单引号，搜索页面直接弹了SQL报错，框渗连堆栈都露出来了。搜索那一刻我意识到，框渗这站点的搜索开发者大概从没想过，有人会往搜索框里丢不是商品名的东西。搜索框的本质是“用户输入→拼接查询→返回结果”，但凡中间少一层转义，整条链就断了。

更常见的玩法是XSS。有些搜索框会把你的输入原样回显在页面上——“您搜索的是：xxx”，如果没过滤，直接塞个<script>进去，等管理员在后台看搜索日志时，cookie就到我手里了。这招不新鲜，但有效得可怕。有个朋友靠这招黑进过某政府网站的舆情监控系统，就因为在搜索框里埋了个payload，等值班人员一搜“信访”，脚本就跑了。

但真正的老手不会只盯着回显。他们看的是搜索框背后的逻辑。比如搜索建议功能——你每敲一个字，前端就向后端发一个AJAX请求，返回联想词。这个接口往往比主搜索更疏于防范。我曾经对一个在线教育平台下手，主搜索过滤得严严实实，但那个自动补全接口直接返回了所有用户的搜索记录，包括一些内部员工搜过的“离职补偿标准”“竞品工资对比”。没打任何数据库，就靠一个没人注意的联想接口。

还有个冷门方向是搜索框的参数污染。有些系统用POST提交搜索词，但同时也接受GET参数。你试着把POST改成GET，加个debug=1，说不定就翻出后台的调试面板。有个案例，某金融APP的搜索框，只要在参数里加admin=true，就能搜出所有用户的身份证号。原因很简单——搜索逻辑里写死了“管理员可以搜全量”，但没校验当前会话是不是管理员。

别把搜索框当输入框看。它是一个反射面，能映出整个系统的架构习惯。开发者怎么处理它，往往就怎么处理其他入口。如果搜索框连最基本的特殊字符都不拦，那登录框、注册框大概率也是裸奔的。

当然，现在主流框架都自带防注入，但总有历史遗留系统，总有赶工期的外包项目。搜索框渗透的门槛低，收益却高——因为它处在用户交互的最前线，任何人的输入都会经过这里，包括那些粗心大意的管理员。

防御也不难，难的是开发者愿不愿意把搜索框当回事。参数化查询、输出编码、最小权限，三件套做完，这扇门就关了一大半。但现实是，很多人觉得搜索框就是个查东西的，能有什么危险。

你猜怎么着？最危险的就是这种想法。