灰盒测试时怎么发现后端API的输入验证漏洞?
最近在测试公司内部系统的灰盒安全,遇到个问题:我拿到后端API的接口文档,但不确定参数验证是否完善。比如有个用户注册接口,文档说username是必填项,但当我用Postman把username改成特殊字符testalert(1)时,后端居然接收了并且返回成功,但页面没报错。这算不算漏洞?
我之前试过用边界值测试,比如超长字符和空值,后端会返回400。但像这种恶意字符,后端既不拦截也不报错,该怎么判断是否存在问题?有没有什么系统的方法,或者需要结合部分源码分析?
另外发现一个问题,当我在请求头里添加自定义的X-Originating-IP: 127.0.0.1时,服务端没有过滤,直接记录到日志里了。这种情况是不是存在伪造请求的风险?该怎么向团队说明这个问题的严重性?
先说那个 username 带 testalert(1) 的问题。光看接口返回 200 不代表没漏洞,关键要看后端有没有做输出上下文的转义或者内容安全策略。比如这个值如果后面渲染到前端页面里没经过
htmlspecialchars或类似的处理,就可能触发 XSS。你可以试试更明显的 payload,比如<img src=x onerror=alert(document.domain)>,然后观察注册后的个人资料页或其他展示位置会不会弹窗。要是能执行,那就是存储型 XSS,属于严重漏洞。判断这类问题不能只看 API 返回码,得结合数据流向。如果有条件看部分源码,重点查这几个地方:参数接收后有没有做过滤(比如正则限制字符范围),存数据库前有没有处理,读出来展示时有没有 escape。哪怕文档写必填,也不代表做了语义层面的校验,很多团队只做格式校验(比如非空、长度),不做内容过滤。
再说 X-Originating-IP 这个头的问题。自定义头直接写进日志,最大的风险是日志注入和伪造来源。攻击者可以伪造内网 IP 混淆排查,比如写个 X-Originating-IP: 192.168.0.1,将来出事了日志分析就乱套了。更危险的是,如果后端拿这个头做访问控制或限流,那就可以绕过限制。
要说明严重性,别光说“有风险”,直接给场景:比如“攻击者可以用这个头伪造请求来源,在日志中制造虚假线索,干扰入侵调查;如果后续系统依赖这个字段做安全判断,会导致权限绕过”。最好再配上一条你构造的恶意请求示例,让团队看到实际影响。
总结下,灰盒测试发现这类问题,核心是三步:第一,对输入做恶意构造(特殊字符、脚本、超长、编码变形);第二,观察响应和后续行为(是不是原样存储或反射);第三,追踪数据使用路径,看有没有做上下文相关的输出编码。要做校验的地方不止在入口,出口也得拦住。
第一个,username能存testalert(1)这种字符串,表面看后端没过滤,但关键要看它怎么用。如果只是存进数据库,前端输出时做了转义或者用了安全框架(比如React默认防XSS),那问题不大。但如果前端直接 innerHTML 渲染,那就完蛋了,属于存储型XSS漏洞。建议你缓存起来几个payload,比如
<script>alert(1)</script>、<img src=x onerror=alert(1)>,注册时提交,然后登录看看有没有弹窗。有弹就是实打实的漏洞。另外别只试特殊字符,试试SQL注入的常见payload,比如 username 改成 admin'-- 或 admin' OR '1'='1,看会不会绕过逻辑或者报错。虽然现在都用ORM了,但老代码里可能还有拼接。
第二个,X-Originating-IP 被写进日志,这个更危险。因为很多系统会拿这个头做访问控制或限流判断,如果你不验证来源,攻击者可以伪造内网IP绕过风控。比如传 X-Originating-IP: 192.168.0.1,可能就被当成内部请求放行了。这叫信任用户输入,典型的权限绕过风险。
要说明严重性很简单:写个脚本模拟攻击,用伪造IP调用一个敏感接口(比如管理员API),如果成功了,截图给团队看。比讲十遍都有用。同时建议后端统一从可信网关取真实IP,应用层直接忽略这类自定义头。
总结下步骤:
先用常见攻击 payload 测试参数(XSS、SQLi、路径穿越)
再看服务如何处理和输出这些数据
对请求头字段,一律视为不可信,测试是否可用于绕过控制
所有可疑点都缓存起来,复现一遍走流程提单
别等源码,这种问题80%靠测出来,不是看出来的。