旁注渗透

去年冬天，旁注渗透我在一个做跨境电商的旁注渗透朋友那儿看到一份后台日志。他网站的旁注渗透订单查询接口有个参数叫order_id，正常请求返回的旁注渗透是JSON格式的订单详情。他随手把参数值后面加了个单引号，旁注渗透页面直接抛出了MySQL语法错误——错误信息里连数据库表名和字段都带出来了。旁注渗透这就是旁注渗透旁注渗透的起点，一个引号，旁注渗透一个不该回显的旁注渗透报错。

旁注渗透，旁注渗透说白了就是旁注渗透不正面攻击目标，而是旁注渗透从它旁边的系统、服务、旁注渗透人员或者供应链下手。旁注渗透你防火墙再厚，旁注渗透WAF再灵敏，总有关联的资产是松的。我见过太多这样的例子：主站HTTPS配置完美，CSP头拉满，结果同一个IP段下有个测试环境跑着三年前的WordPress，插件漏洞一抓一个准。攻击者拿下测试机，翻出数据库配置文件，发现里面写着生产库的只读账号密码。虽然只是只读，但订单表、用户表全在里面躺着。

这种路径不是理论。2019年Capital One那件事，核心问题就是WAF配置错误导致SSRF，攻击者通过一个元数据接口拿到了临时凭证，然后横向到S3存储桶。整个过程没有“攻破”Capital One的主站，而是利用了云环境里一个不起眼的配置疏漏。旁注的本质是：你的安全边界不是你以为的那条线，而是所有关联资产里最弱的那一环。

具体怎么找旁注入口？我自己的习惯是先做资产测绘。用FOFA或者Shodan搜一下主域名对应的C段，看看有没有暴露的Jenkins、GitLab、Nexus这些开发工具。再查一下ICP备案，同一主体下的其他域名往往安全投入少得多。还有更土的——领英上搜目标公司的运维工程师，看他个人GitHub有没有提交过带内网IP的配置文件。这些信息拼起来，旁注的路线图就出来了。

旁注渗透里有个很关键的技巧叫“信任传递”。比如目标公司用了一个SaaS服务做客服工单，这个SaaS的API密钥可能被硬编码在某个前端JS文件里。拿到密钥，你就能以客服身份读取工单内容，里面经常有用户提交的密码重置链接或者内部系统截图。这不是直接打穿，而是借别人的手递刀子。

防守方要堵这条路，光靠堆设备没用。我见过一个做得不错的团队，他们把生产环境、测试环境、办公网做了严格的网络隔离，测试环境不允许访问生产数据库，办公网访问任何内部系统都要经过零信任网关。开发人员本地起服务用的数据库密码是假的，真密码只在CI/CD流水线里注入。这样即使测试机被拿下，也摸不到生产数据。

但大多数公司做不到这么细。现实是，一个业务跑起来，运维随手在云主机上开了个8080端口跑Spring Boot Actuator，没加认证，/env端点直接吐出来数据库连接串。这个端口可能不在任何资产清单里，安全团队根本不知道它存在。旁注渗透打的就是这种“影子资产”。

说到底，旁注渗透考验的不是单点突破能力，而是对目标整体暴露面的理解。你得像拼图一样，把域名、IP、证书、代码仓库、员工社交账号这些碎片拼起来，找到那条没人注意的缝隙。缝隙往往不在正门，而在隔壁那扇没锁的窗户。