在应用程序安全环境中，我每天都使用 Fortify Software 的 Fortify360。
我最大的障碍之一是解释数字（源与汇）
Fortify 将源代码中向用户显示未验证数据的每个位置标记为跨站点脚本漏洞。
假设有 300 个位置（接收器）向用户显示未经验证的数据。在这 300 个接收器中，所有数据都是使用一个函数从数据库中提取的。（来源）
Fortify 随后将报告存在 300 个跨站点脚本漏洞。它没有明确告诉您的是，其中 300 个可能是从同一位置修复的。
我的问题是，从应用程序安全工程师的角度来看，您是否向您的客户报告存在 300 个跨站点脚本漏洞或 1 个跨站点脚本漏洞？这些陈述中的任何一个都是准确的吗？
你报告源还是汇？
我目前正在做的是报告有 300 个潜在的跨站点脚本漏洞，这些漏洞可能都可以在一个函数/方法中修复。
说有 1 个跨站点脚本漏洞暴露在 300 个位置更准确吗？
我意识到其中一些是主观的，但我正在寻找该领域其他人的意见，他们可以对他们的方法有所了解。
我要重申 AviD 的回复 - 跨站点脚本通常作为上下文敏感的输出编码问题而不是输入验证问题更好地解决。如果您尝试将其作为输入验证问题来解决，那么在许多情况下，您将鼓励使用黑名单输入验证方法，或者如果您使用的是白名单方法，您可能无法将其作为紧缩成你想要的样子。
此外 - 您需要为每个输出编码上下文（HTML、属性、CSS、JavaScript）处理的内容会有所不同，因此我建议您引导开发团队使用 Microsoft 的 WPL（Web保护库）或其他语言的 OWASP ESAPI 或 OWASP 改革。
我个人的偏好（请记住，我为供应商 IBM 工作，但这是我自己的意见）是，修复的最佳报告方法是提供源和接收器。
我想说，在 .NET 框架中尤其如此，其中不同的输出控件（接收器）对传递给它们的数据进行不同的编码，并且不同的输入控件（源）并不总是从其 url 编码形式中取消编码数据。
使用 Java，您通常不会看到太多的可变性，但是，我认为在决定最佳修复之前，您仍然必须同时考虑源和接收器。
我几乎总是将其描述为一个漏洞，它显示在 300 个位置 - 特别是如果这是更广泛的报告的一部分，其中可能存在 50、100 或更多漏洞，否则您最终会得到一份厚如书的报告，其中没有 -一个人可以采取行动。
从观众的角度来想一想——他们会想知道他们面临的风险以及他们能做些什么。他们的行动将是指派个人或团队进行修复，因此他们宁愿被告知有一个问题需要修复 - 出现的 300 个实例可能使其比具有漏洞的漏洞具有更高的优先级一个可见的实例，但补救措施可能相同。
在我看来，XSS 在哪里以及如何使用它既重要又不重要。
没关系，因为任何 XSS 在某种程度上都是危险的。
这确实很重要，因为看起来无害的 URI 和参数结构中的 XSS 必然会导致更多的网络钓鱼。在许多方面（从攻击者的角度来看），最好在页面上提供 XSS，该页面对应用程序或基础架构的经过身份验证和未经身份验证的访问者/用户都可用。
当您将其表述为 SQLi 而不是 XSS 时，情况变得更加相关且易于理解。每个 SQLi 实例都可以转化为可利用性的练习。盲 SQLi 通常更难利用，但这并不重要——真正的关键是每个单独的 SQLi 缺陷暴露了哪些数据或未经授权的访问。我想到了 CVSS 和 DREAD，但实际上这应该像 CWSS 和 STRIDE 一样更加优化。
所以——回答你的问题——决定应该是应用安全风险管理中的一个练习。每个漏洞类别可能会有超过 1 个甚至少于 300 个单独的发现。我更喜欢将它们称为软件弱点，但这可能会因您的目标受众而异。在呈现信息时，特别是在报告撰写工作中，针对目标受众进行定制始终很重要。
同样，是否列出源或接收器（或两者）取决于目标受众。如果我收到报告，我希望看到两者——但那是因为我是应用程序的深度技术评估者。接收器对大多数开发人员最有用——它可以让他们专注于根本原因问题——即编码（在 XSS 和 SQLi 的情况下）——但是，可能还有其他补救措施和深度防御为开发人员以及 DBA、系统管理员、经理以及参与应用程序和系统生命周期的任何其他人提出的策略。
所以我的回答是，这个答案高度依赖于数以千计或数百万个其他因素。