凌晨两点十七分，渗透回显我盯着屏幕上那行代码，渗透回显它像一条蛇，渗透回显缓慢地吐着信子——echo $USER_INPUT。渗透回显这不是渗透回显什么高深的技术，任何一个写过两天PHP的渗透回显人都能看出来，这是渗透回显最原始的反射型XSS漏洞。可就是渗透回显这行代码，让我在客户的渗透回显生产环境里，拿到了他们财务系统的渗透回显管理员Cookie。

渗透测试这行干久了，渗透回显你会对“回显”这两个字产生某种病态的渗透回显敏感。它太朴素了，渗透回显朴素到大部分开发人员根本不会多看它一眼。渗透回显用户输入什么，渗透回显页面就原样吐出来什么，这有什么问题？问题大了。回显的本质是数据流动的终点，是用户可控内容与系统输出之间的最后一道闸门。闸门没关严，你输入的东西就会变成代码，在别人的浏览器里跑起来。

那家客户的系统有个搜索框，用来查订单号。我随手敲了个<script>alert(1)</script>，回车。弹窗跳出来的瞬间，我心里咯噔一下——不是高兴，是那种“又来了”的疲惫。因为这意味着接下来几个小时，我得把这个简单的弹窗升级成能窃取Cookie的武器，得绕过他们那套看起来花了不少钱买的WAF，还得在报告里用最平实的语言告诉甲方：“您这个搜索框，能把用户的登录凭证送给任何人。”

回显漏洞的可怕之处在于它的“诚实”。它不跟你玩什么逻辑绕弯，你给什么它就还什么。反射型XSS、命令注入、SQL注入的报错回显、SSRF打回来的内网banner——这些全是回显的不同面孔。我见过一个运维小哥，在调试接口时把curl的返回直接print到前端页面，结果那接口能访问内网元数据服务，AWS的临时凭证就这么明晃晃地挂在浏览器里。他当时还跟我说：“这接口没人知道地址。”可回显这东西，一旦存在，被发现只是时间问题。

有人觉得XSS不如RCE刺激，弹个框能有多大危害？这种想法挺外行的。去年有个电商站，商品评论区存在存储型XSS。攻击者没弹窗，他注入了一段JS，专门偷用户的收货地址和手机号。三天，两万条数据。回显在这里变成了一个静默的抽水机，用户毫无感知，平台毫无告警。等发现的时候，数据早就在暗网打包出售了。

防御回显漏洞，说复杂也复杂，说简单也简单。输出编码，上下文感知的那种。别用黑名单过滤<script>，那玩意儿绕过的姿势比你想的多得多。我见过用<img src=x onerror=alert(1)>的，见过用javascript:伪协议的，见过把payload拆成多个参数拼凑的。黑名单就像拿渔网挡子弹，看着挺密，其实全是洞。

还有个更隐蔽的问题：回显不一定在HTML里。JSON接口的回显、HTTP头部的回显、甚至日志文件里的回显，都可能成为突破口。我曾在一次内网渗透中，通过一个API的错误回显拿到了数据库的连接字符串。那接口把异常信息原样返回，包括堆栈、SQL语句、甚至数据库账号密码。开发人员大概觉得“反正只有内部调用”，可内部调用不代表安全，只代表攻击面小一点而已。

写渗透报告的时候，我通常会把回显漏洞放在“高危”那一栏。不是因为它技术难度高，恰恰相反，是因为它太容易被忽视。一个搜索框、一个错误页面、一个调试接口，都可能变成入口。而入口一旦打开，后面的故事就不是开发人员能控制的了。

凌晨三点零四分，我关掉Burp Suite，把PoC截图保存好。屏幕上那个搜索框还在，安安静静地等着下一个输入。它不知道，自己刚刚差点成了整个财务系统的后门。回显就是这样，平时人畜无害，关键时刻能要命。