OWASP Top 10漏洞解析（3）- A3:Injection 注入攻击

作者：gentle_zhou

原文链接：OWASP Top 10漏洞解析（3）- A3:Injection 注入攻击-云社区-华为云

---

Web应用程序安全一直是一个重要的话题，它不但关系到网络用户的隐私，财产，而且关系着用户对程序的新人。随着Web应用程序功能持续增加，复杂性不断提高，这些程序也面临着越来越多的安全威胁和挑战。

为了帮助这些应用程序的开发团队和安全人员了解和防范这些威胁，提高安全意识，编写更安全的代码，OWASP（Open Web Application Security Project，开放式Web应用程序安全项目）发布了一份标准指南，称为OWASP Top 10。

这是一份关于Web应用程序安全风险的标准指南，它基于全球范围内的安全专家和数据提供者的共识，列出了当前最严重、最关键的10种Web应用程序安全风险，并提供了相应的防范措施和建议。OWASP Top10 每隔几年会更新一次（目前已经发布了六个版本，分别是2004年、2007年、2010年、2013年、2017年和2021年），最新的版本是在2021年发布的OWASP Top10:2021。

已解析的OWASP漏洞

1. OWASP Top 10漏洞解析（1）- A1:Broken Access Control 访问控制失效：OWASP Top 10漏洞解析（1）- A1:Broken Access Control 访问控制失效-云社区-华为云
2. OWASP Top 10漏洞解析（2）- A2:Cryptographic Failures 加密机制失效：OWASP Top 10漏洞解析（2）- A2:Cryptographic Failures 加密机制失效-云社区-华为云

“注入攻击”缺陷详情

今天，就来为大家讲解其中的第三条缺陷：Injection 注入攻击，它从2017年版本下滑到2021年版本的第三位。

注入攻击是一种网络安全威胁，它利用了应用程序对用户输入的数据没有进行充分的验证，从而导致恶意数据被当作代码来执行产生的漏洞；其目的通常是获取程序内敏感信息、执行非法操作、破坏系统功能或完整性等。注入攻击可以影响各种类型的应用程序，包括Web应用、数据库应用、命令行应用等。

注入攻击的本质是程序内违反了数据与代码分离的原则，即用户输入的数据被拼接到原本要执行的代码中，从而改变了代码的语义或结构。

注入攻击发生的两个关键条件是：

1. 用户可以控制输入数据
2. 代码拼接了用户输入的数据，并带入程序中去执行

94%的应用程序会被某种类型的注入攻击所测试，一共最高发生27.4万次，其中成功概率最高达19%，平均达3%。这里值得注意的是，一些经典有名的CWE缺陷中，就包括该缺陷，比如CWE-89：Improper Neutralization of Special Elements used in an SQL Command SQL注入攻击，CWE-77 Improper Neutralization of Special Elements used in a Command 命令注入攻击，CWE-79 Improper Neutralization of Input During Web Page Generation 跨网站脚本攻击。

常见的注入攻击缺陷类型

一个应用程序在如下场景下容易被该缺陷攻击：

• 应用程式未验证、过滤或清理用户提供的数据
• 在interpreter解释器中未直接使用上下文感知转义的动态查询或非参数化调用
• Hostile data恶意数据在对象关系映射(ORM)搜索参数中使用，用来提取额外的敏感记录
• Hostile data恶意数据被直接使用或被连接。SQL或命令包含了动态查询、命令或存储过程中的结构和恶意数据。

一些常见的注入攻击包括SQL, NoSQL, OS 命令，对象关系映射（ORM），LDAP，以及表达式语言（EL）或对象图像导航库（OGNL）注入。这个概念在所有的解释器都是相同的。如果应用程序存在注入攻击的弱点，源码检查是最好的方式，强烈建议对所有输入的参数、标头、URL、cookies、JSON、SOAP 以及 XML 的资料进行自动化测试。组织可以将静态源码测试（SAST），动态应用检测（DAST）工具，交互式应用安全测试（IAST），融入到CI/CD流水线中，以达到在上线部署前能识别注入攻击缺陷的目的。

如何防止该缺陷的发生

如何防止该缺陷的发生，也很简单，我们只需要将数据和命令以及查询分割开来：

• 首选项就是使用安全的API，避免完全使用解释器（interpreter），提供一个参数化的界面或则将API融合到对象关系映射（ORM）工具中去。注意：即使已经参数化了，在储存的程序中仍然有可能引入SQL注入攻击，如果用户是通过PL/SQL 或 T-SQL 来连接查询和数据，或则通过使用EXECUTE IMMEDIATE 或 exec() 来执行恶意数据。
• 使用正面的服务端输入验证。这其实不是一个完整的防御，因为许多应用程序需要特殊的字符，比如文本区域或则移动应用程序的API。
• 对于任何有残差的动态查询，使用该解释器的特定转义语法来转义特殊字符。注意:SQL结构(比如表名、列名等)不能转义，因此用户提供的结构名是危险的，这可以说是报告编写软件中常见的问题。
• 在查询中使用LIMIT 以及 其他SQL控制，用来防止遭遇SQL注入攻击时，记录被大量泄露。

举个栗子

场景1

一个应用程序中，使用了下方这样易受攻击的SQL调用构造，并且在其中使用了不受信任的数据:
String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

场景2

类似地，应用程序对其中使用的框架的盲目信任，可能会导致查询容易受到攻击；比如，HQL Hibernate 查询语言：
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

在上面两种情况下，攻击者可以通过修改浏览器中的“id”参数值来发送: ‘UNION SLEEP(10);’. 比如说这样：
http://example.com/app/accountView?id=' UNION SELECT SLEEP(10)

这将改变这两个查询原本的含义，将会返回帐户表中的所有记录。更危险的攻击可能会修改或删除数据，甚至调用存储过程。

参考链接

1、https://owasp.org/Top10/A03_2021-Injection/