问题描述
可以在 REST API 上发生反射型 XSS（跨站点脚本）攻击，该 API 接受 XML 请求有效负载，提供 XML 响应。请求或响应中没有 html 内容。
我已经阅读了很多关于 XSS 的文档，现在我认为这不适用于不提供 html 内容的 REST API，这种理解是否正确？ 然而，我们正在对收到的请求进行验证，以检查输入中是否有任何类型的标签 ()，以及其他一些业务级别的验证。
关于我们服务的几点，
- 我们的 REST API 不会接收或响应 HTML 数据。
- 我们不会直接从最终用户那里获得任何输入或请求 （攻击者的可能性主要来自恶意的最终用户）
- 我们不会直接向最终用户发送 XML 响应/HTML 呈现 XSS 几率最高的系统（浏览器）。
- 我们接受请求并将响应传递给我们的内部服务 企业和值得信赖的（合作伙伴）。
- 我们发送的 XML 响应仅用于读取嵌入在 非 html 环境（这些是读取我们响应的受信任服务）。
这种情况下发生 XSS 的风险有多大？
（此查询背后的原因是我们收到了 checkmarx 高严重性错误，其中表明我们很容易发生反射型 XSS，我认为在我们的案例中这可能是误报。我们正在使用 Spring Boot 应用程序.)
解决方法
这主要取决于响应 content-type。只要它是类似 applicatiin/xml 或 text/xml（而不是 text/html 或 application/xhtml）的东西，api 本身就不容易受到 xss 的攻击，因为现代浏览器不会运行即使显示脚本。
请注意，尽管它可能仍然容易受到 xml 注入，如果 Checkmarx 发现它是 xss，则可能存在某种可能的注入。确保用户无法在响应中创建 xml 标记或属性。这样做的方法与防止 xss 的方法非常相似。请注意，将用户输入写入 xml 时不需要对用户输入进行 html 编码，因为它不是 html，但您需要对值进行 xml 编码。
另请注意，验证输入很好，但一般来说，上下文感知输出编码可以防止注入攻击，即。将适当的编码类型应用于值、xml 属性等。很多时候，您无法在输入端完全实现这一点。 （输入验证仍然有意义，您也应该这样做，但最好通过输出编码来防止注入。）