如果参数化查询是从可信应用系统中检索的输入，如何解决扫描的 sql 注入问题？
How to resolve the scanned sql injection problem if the parameterized query is an input that is retrieved from a trusted application system?
我有 2 个应用程序使用 Kafka 主题相互通信。第一个应用程序获取输入的客户 ID，并根据客户类型转到受信任的内部查询库（公司中的第三个应用程序）以获取需要为该客户执行的所有查询。所有查询都是参数化的，并且根据客户的类型，提取的查询可能会有所不同。这些查询使用查询计划 ID 在逻辑上保存在同一查询组下。每个查询和用户输入参数都构建在消息负载中，然后发送到第二个应用程序订阅的主题。第二个应用程序将使用准备好的语句和用户输入来完成查询，然后根据数据库的类型，使用正确的 JDBC 适配器在正确的数据库上执行查询（我们使用通用代码针对不同的数据库、oracle、PostgreSQL 等执行查询）。
实现功能后，我们 运行 对两个应用程序进行静态扫描。由于 "SQL query built with input that comes from an untrusted source." 的原因，第二个应用程序收到 SQL 注入警报 尽管参数化查询位于第二个应用程序的请求消息有效负载中，但查询是从受信任的查询清单库中获取的。我可以标记这些 SQL 注入 NAI - 不是问题吗？
视情况而定。
如果您已验证该值来自可信来源（或由可信来源验证），它会降低出现漏洞的风险 - 但您还应该考虑您的 trust boundaries系统。
这两个系统是否在同一信任边界内，或者数据是否跨越信任边界？仅仅因为您信任系统 A 和系统 B，并不 必然 意味着 B 不必验证来自 A 的数据。定义信任边界时需要考虑的事项：
- 接收系统是否有可能暴露在外部或其他系统中？对于未来的开发人员来说，这个系统没有验证输入是否很明显？开发人员喜欢重用 API，这通常很好，但如果假设不明确，可能会导致安全漏洞？
- 您想跨系统提供 defense in depth 吗？如果系统 A 受到损害（通过漏洞），您是否希望系统 B 也受到损害，或者您是否希望在此系统中有更多的防御层？
您将这些描述为 "applications" 的事实通常向我表明您应该将它们归类为不同的信任边界，尤其是当它是安全敏感系统时。但无论您做出什么决定，都应该明确说明，并记录（在代码和体系结构图中，如果有的话）您所做的假设。如果您确定这两个应用程序是同一信任边界的一部分，您应该确保记录接受这些应用程序的 API 是内部的并且不会验证输入。
定义您的信任边界是定义整体 threat model 的一部分。即使您不使用正式的威胁建模，这些概念也提供了一个有用的框架来思考设计决策。
我有 2 个应用程序使用 Kafka 主题相互通信。第一个应用程序获取输入的客户 ID，并根据客户类型转到受信任的内部查询库（公司中的第三个应用程序）以获取需要为该客户执行的所有查询。所有查询都是参数化的，并且根据客户的类型，提取的查询可能会有所不同。这些查询使用查询计划 ID 在逻辑上保存在同一查询组下。每个查询和用户输入参数都构建在消息负载中，然后发送到第二个应用程序订阅的主题。第二个应用程序将使用准备好的语句和用户输入来完成查询，然后根据数据库的类型，使用正确的 JDBC 适配器在正确的数据库上执行查询（我们使用通用代码针对不同的数据库、oracle、PostgreSQL 等执行查询）。
实现功能后，我们 运行 对两个应用程序进行静态扫描。由于 "SQL query built with input that comes from an untrusted source." 的原因，第二个应用程序收到 SQL 注入警报 尽管参数化查询位于第二个应用程序的请求消息有效负载中，但查询是从受信任的查询清单库中获取的。我可以标记这些 SQL 注入 NAI - 不是问题吗？
视情况而定。
如果您已验证该值来自可信来源（或由可信来源验证），它会降低出现漏洞的风险 - 但您还应该考虑您的 trust boundaries系统。
这两个系统是否在同一信任边界内，或者数据是否跨越信任边界？仅仅因为您信任系统 A 和系统 B，并不 必然 意味着 B 不必验证来自 A 的数据。定义信任边界时需要考虑的事项：
- 接收系统是否有可能暴露在外部或其他系统中？对于未来的开发人员来说，这个系统没有验证输入是否很明显？开发人员喜欢重用 API，这通常很好，但如果假设不明确，可能会导致安全漏洞？
- 您想跨系统提供 defense in depth 吗？如果系统 A 受到损害（通过漏洞），您是否希望系统 B 也受到损害，或者您是否希望在此系统中有更多的防御层？
您将这些描述为 "applications" 的事实通常向我表明您应该将它们归类为不同的信任边界，尤其是当它是安全敏感系统时。但无论您做出什么决定，都应该明确说明，并记录（在代码和体系结构图中，如果有的话）您所做的假设。如果您确定这两个应用程序是同一信任边界的一部分，您应该确保记录接受这些应用程序的 API 是内部的并且不会验证输入。
定义您的信任边界是定义整体 threat model 的一部分。即使您不使用正式的威胁建模，这些概念也提供了一个有用的框架来思考设计决策。