security - 可以在服务于非 HTML 响应的 REST API 上发生反射 XSS(跨站点脚本)攻击

Question

可以反射(reflect) XSS(跨站点脚本)攻击发生在 REST API 上，它接收 XML 请求负载，提供 XML 响应。请求或响应中没有html内容。

我已经阅读了很多关于 XSS 的文档，现在我认为这不适用于不提供 html 内容的 REST API，这种理解是否正确？然而，我们正在对收到的请求进行验证，以检查输入中是否有任何类型的标签 (<>)，以及一些其他业务级别的验证。

关于我们服务的几点，

1. 我们的 REST API 不接收或响应 HTML 数据。
2. 我们没有直接从最终用户那里获得任何输入或请求(攻击者的可能性主要来自恶意终端用户)
3. 我们不会直接向最终用户/HTML 呈现发送 XML 响应XSS 机会最高的系统(浏览器)。
4. 我们接受请求并将响应传递给我们的内部服务企业和值得信赖的(合作伙伴)。
5. 我们发送的 XML 响应仅用于读取嵌入在非 html 环境(这些是正在阅读我们的回复的可信服务)。

在这种情况下，XSS 的风险有多大？

(此查询背后的原因是我们收到了一个 checkmarx 高严重性错误，它表明我们容易反射 XSS，我认为这在我们的案例中可能是误报。我们正在使用 spring boot 应用程序.)

Answer 1

这主要取决于响应content-type。只要它是类似 applicatiin/xml 或 text/xml 的东西(而不是 text/html 或 application/xhtml), api 本身不易受到 xss 攻击，因为现代浏览器即使显示也不会运行脚本。

请注意，它可能仍然容易受到 xml 注入(inject)的攻击，如果 Checkmarx 发现它是 xss，则可能存在某种可能的注入(inject)。确保用户不可能在响应中创建 xml 标记或属性。这样做的方法与防止 xss 的方法非常相似。请注意，虽然您在将用户输入写入 xml 时不需要对用户输入进行 html 编码，因为它不是 html，但您需要对值进行 xml 编码。

另请注意，验证输入很好，但通常情况下，注入(inject)攻击可通过上下文感知输出编码来防止，即。将适当的编码类型应用于值、xml 属性等。很多时候你无法在输入端完全实现这一点。 (输入验证仍然有意义，您也应该这样做，但最好通过输出编码来防止注入(inject)。)