注入漏洞是设计缺陷还是实现缺陷？

Question

注入漏洞主要是设计问题还是实现问题？我以SQL注入为例；我也对其他注入漏洞感兴趣。

我认为这是懒惰编程的直接后果。

• 缺乏投入消毒
• 缺少参数化(不使用API，而是直接使用字符串在代码中构建SQL命令)

一些人说这主要是一个设计缺陷，但我不知道为什么.

Answer 1

这两者都可以，但这些问题的主要责任是设计。

独立于设计，如果开发人员没有被迫创建易受SQL注入影响的代码，但仍然创建它，则这是一个实现问题。这意味着，开发人员要么不理解问题，要么理解，但不想创建一个抵抗它的代码。

如果存在使用本机SQL或HQL或JPQL或类似的设计决策，而不是使用准备好的语句(在Java中)，或者使用某些DSL或类似技术，则这样的决定使代码中容易出现SQL注入问题。对SQL注入的抵抗并不是准备好的语句的主要目标，而是一个积极的副作用。然而，允许原生SQL的设计决策意味着设计问题。

如果对于原生SQL没有明确的设计决策，那么开发人员就没有明确的实现数据访问层的指导方针，如果他们没有足够的经验，那么很容易犯这样的错误，并创建易受SQL注入影响的代码。这意味着，没有任何关于普通SQL的决定也是糟糕的设计，因为它没有解决如此重要的方面。

Answer 2

注入(如SQL注入、XSS等)是可能的，因为代码和数据在同一个字符串中可能组合在一起，而且开发人员使用不受信任和未充分验证的用户输入来构造此类字符串。

将代码和数据混合在同一个字符串中的可能性在SQL、HTML+Javascript、.这类似于计算机中的内存页同时具有可读性、可写性和可执行性--这在很长一段时间内是常见的，但现在人们试图清楚地将内存中的代码(可执行文件)和数据(可读、可写)分开。因此，可以将字符串中的代码和数据混合称为设计问题，特别是因为在许多情况下，可以创建一个代码和数据清晰分离的设计。

但是，也有人可能会指出，在许多情况下，存在使用函数构造安全的code+data字符串的方法，这些函数将代码和数据清晰地分开作为输入，例如，为SQL语句绑定参数。因此，人们可能会争辩说，在应用程序中，不使用这些函数是设计问题。在某些情况下，不提供这样的功能将是使用的框架的设计问题。

这样的设计问题就会导致实现问题。理论上，如果没有参数绑定等安全函数的帮助，就可以构造一个安全的code+data字符串，因为“只需要”进行适当的转义和引用。因此，不恰当地这样做是一个实现错误。

Answer 3

如果有一位称职的软件架构师，我会说最大的问题往往是实现，更具体地说，就是缺乏安全编码最佳实践方面的知识和培训的个人。

为了限定这个简短的答案，我将与设计进行对比，表明设计涵盖了广阔的空间，有些设计是由其他人规定和定义的，其余的，你可以定义。

下面是需要考虑的所有层，从编码器的末尾开始：

1. 实现
2. 设计
3. 系统体系结构
4. 框架与图书馆
5. 行业期望

行业期望是影响软件开发人员及其客户的习惯、真理、误解、炒作和客户感知。这主要是规定的设计。

框架4.通常受行业预期和规范5的影响，但随着时间的推移，它会反过来反馈:新框架是用新的想法(有时是以安全性为中心)构建的，以改进行业期望和规范5。一个新框架的例子: Google允许移动应用程序直接在客户端定义一个查询，然后该框架负责数据库上的序列化和远程执行；服务器上的javascript安全文件具有很大的灵活性，而安全分析人员可以很快地检查这些问题并发现任何问题。这也是规定的设计。

系统架构3.通常是用4.和5来准备的。构建RESTFul API服务(框架)的决定基于软件体系结构决策3.，并受限于框架4.设计的工作方式。更安全的系统架构选择可能是GraphQL，因为RESTFul API需要更多的人工编码，同时也存在常见的人为错误问题。

系统架构3.也不仅仅是软件体系结构。它选择正确的框架4.以及软件栈和托管系统来构建解决方案。选择一个很少为人所知的框架和一个小型的开发人员社区意味着有低的审查和没有经过时间考验的成熟。选择一个没有发布安全实践的小型虚拟机托管提供商可能是一个很大的负担。

我将设计2视为系统架构3.、框架4.和行业期望5的一个独特项目。设计不是关于系统，而是更多关于客户需求，通常是以数据为中心的方式。我说，以数据为中心，因为安全最终是围绕授权和对特定数据的访问实现的，因此，对数据模型进行有授权意识的设计可以改善安全结果。因此，虽然实现可能很关键，但这种设计水平是可以控制的，而且可能会失败。

最后，在这里的答案中已经很好地表示了实现1。软件编码人员应该知道他们的工艺，采用设计2并使用安全模式编写代码。如果以上所述，仍然存在安全故障，那么这可能是一个知识和培训问题，因为软件编码人员应该以最佳实践方式遵循“计划”，而不是自由操作。