这是一个非常简单的情况。我们有一个数据库表，它有一个VARBINARY(MAX)字段，这个字段包含一个文本文件。在。net端，用户可以从数据库中下载文本文件。它只是纯文本，来自可信任的来源。然而，fortify/checkmarx抱怨存储的XSS。代码非常简单。
Response.Clear()
Response.ContentType = "text/plain"
Response.AddHeader("content-disposition, $"attachment;filename=FileToDownload.txt")
Response.BinaryWrite(datafromDB)
Response.[End]()
漏洞扫描指向Response.BinaryWrite()和Stored XSS的抱怨，当然，考虑到它来自可信来源，这是愚蠢的。然而，我想找到一种方法来纠正这一点，是否有办法从数据库中过滤出"数据"?对象，或者在它到达response.BinaryWrite.
如果响应是文本，则转义不应将内容更改为可能被利用的形式。您应该在数据发送到客户端之前对其进行转义，原因如下:
- "信任data"不存在。你没有考虑:
- 不满的员工可能会更改数据库中的数据并注入可利用的内容。
- 数据进入数据库的路径可能不止一条。并非所有这些路径都可以在数据写入DB之前对其执行清理。通过离线机制将数据导入后端数据库的应用程序通常很常见。
- 漏洞分析不考虑内容类型，因为设置内容类型本质上是"控制流程";分析。目前的漏洞分析技术(数据流分析)通过分析数据从源(DB)到接收(响应流)的路径来识别漏洞利用模式。设置内容类型不在该数据流路径上;即使是，也不会评估静态字符串内容如何影响响应对象的状态，因为它是控制流更改。
如果你标记为"Not Exploitable"事实上，对于处于当前状态的代码来说，它是不可利用的。但是，如果后来有人在不改变数据流中涉及的代码的情况下更改了编码值，则保持网元标记。因此，您将有一个未被发现的"假阴性"。因为控制流改变了，使得代码可以被利用。
依赖于"补偿控制";例如设置响应头或依赖于部署配置/环境控制，直到它不起作用。最终，有人可能会决定进行更改，删除补偿控制(例如，在这种情况下更改响应内容类型)，用于证明标记不可利用的东西而不是正确地修复问题。然后它就变成了一个安全漏洞，可能就在外面等着别人去发现和利用。
我完全支持依赖补偿控件，但随之而来的是需要确保对补偿控件的更改被检测到。实现适当的补救通常比在检测对补偿控制的更改中添加更多的自动化更容易。当一切都失败时，软件实现是最后一道防线。