大家好，又见面了，我是你们的朋友全栈君。

OWASP TOP10系列之#TOP1# A1-注入类

提示：本系列将介绍OWASP TOP10 安全漏洞相关介绍，主要针对漏洞类型、攻击原理以及如何防御进行简单讲解；如有错误，还请大佬指出，定会及时改正~

前言

在OWASP（开放式Web应用程序安全项目）公布的10项最严重的Web 应用程序安全风险列表的在 2013、2017 的版本中都是第一名

一、注入类漏洞是什么？

注入类漏洞是利用应用程序弱点，通过恶意字符将恶意代码写入数据库，获取敏感数据或进一步在服务器执行命令
几乎任何数据源都可以是注入向量，比如环境变量、参数以及用户信息等等，当攻击者可以向程序发送恶意数据时，就会出现注入缺陷
注入缺陷非常普遍，尤其是在代码中。一些更常见的注入有SQL、NoSQL、OS命令、对象关系映射（ORM）、LDAP和表达式语言（EL）或对象图导航库（OGNL）注入
检查代码时很容易发现注入缺陷，源代码检查是检测应用程序是否易受注入攻击的最佳方法，紧随其后的是对所有参数、头、URL、cookie、JSON、SOAP和XML数据输入进行彻底的自动化测试。还可以使用包括静态源（SAST）、动态应用程序测试（DAST）工具以及IAST（交互式应用安全测试），以在生产部署之前识别引入的注入缺陷。

二、什么情况下会产生注入类漏洞问题？

1 应用程序不会验证、过滤或清理用户提供的数据；
2 在对象关系映射（ORM）搜索使用恶意数据参数，用于提取额外的敏感记录；
3 恶意数据被直接使用或连接，比如SQL或执行CMD命令时，在动态查询、命令或存储过程中使用
包含结构数据和恶意数据。

三、如何预防？

1 将数据与命令和查询分开，使用安全的API，提供参数化接口并正确使用对象关系映射工具（ORM）
2.对服务器端输入进行验证，必要时需要对特殊字符进行转义、正则匹配等

四、具体示例

1.SQL注入

攻击者修改浏览器中的 ‘id’ 参数值以发送：’ 或 ‘1’=‘1
http://example.com/app/accountView?id=’ or ‘1’=’1

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

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" 
+ request.getParameter("id") + "'");

2.OS命令注入

以下的代码使用系统属性 APPHOME 来确定它的安装目录，然后根据指定目录的相对路径执行初始化脚本
（错误代码）
示例语言： Java

String home = System.getProperty("APPHOME");
字符串 cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);

上面的代码允许攻击者通过修改系统属性 APPHOME 指向包含恶意版本的 INITCMD 的不同路径，以应用程序的提升权限执行任意命令。因为程序不会验证从环境中读取的值，如果攻击者可以控制系统属性 APPHOME 的值，那么他们就可以欺骗应用程序运行恶意代码并控制系统。

3.XPath注入

与SQL 注入类似，当网站使用用户提供的信息为 XML 数据构建 XPath 查询时，就会发生 XPath 注入攻击。通过故意向网站发送格式错误的信息，攻击者可以找出 XML 数据的结构，或者访问他们通常无法访问的数据。如果 XML 数据用于身份验证（例如基于 XML 的用户文件），他们甚至可以提升他们在网站上的权限。

查询 XML 是使用 XPath 完成的，XPath 是一种简单的描述性语句，允许 XML 查询定位一条信息。与 SQL 一样，您可以指定要查找的某些属性和要匹配的模式。对网站使用 XML 时，通常接受查询字符串上的某种形式的输入，以标识要在页面上定位和显示的内容。必须清理此输入以验证它不会弄乱 XPath 查询并返回错误的数据。

XPath 是一种标准语言；它的符号/语法总是独立于实现的，这意味着攻击可能是自动化的。没有不同的方言，因为它发生在对 SQL 数据库的请求中。

因为没有级别访问控制，所以可以获取整个文档。我们不会遇到任何限制，正如我们可能从 SQL 注入攻击中了解到的那样。

比如
假设我们在网页上有一个用户身份验证系统，该系统使用此类数据文件来登录用户。一旦提供了用户名和密码，软件可能会使用 XPath 来查找用户：

<?xml version="1.0" encoding="utf-8"?>
<Employees>
   <Employee ID="1">
      <FirstName>Arnold</FirstName>
      <LastName>Baker</LastName>
      <UserName>ABaker</UserName>
      <Password>SoSecret</Password>
      <Type>Admin</Type>
   </Employee>
   <Employee ID="2">
      <FirstName>Peter</FirstName>
      <LastName>Pan</LastName>
      <UserName>PPan</UserName>
      <Password>NotTelling</Password>
      <Type>User</Type>
   </Employee>
</Employees>

String FindUserXPath;
FindUserXPath = "//Employee[UserName/text()='" + Request("Username") + "' And
        Password/text()='" + Request("Password") + "']";

使用普通的用户名和密码，此 XPath 可以工作，但攻击者可能会发送错误的用户名和密码并在不知道用户名或密码的情况下选择 XML 节点，如下所示：

Username: blah' or 1=1 or 'a'='a
Password: blah

FindUserXPath becomes //Employee[UserName/text()='blah' or 1=1 or
        'a'='a' And Password/text()='blah']

Logically this is equivalent to:
        //Employee[(UserName/text()='blah' or 1=1) or
        ('a'='a' And Password/text()='blah')]

在这种情况下，只有 XPath 的第一部分需要为真。密码部分变得无关紧要，用户名部分将匹配所有员工，因为“1=1”部分。

XPath 注入防御
1.使用XPath 变量解析器
2.就像避免 SQL 注入的技术一样，您需要使用参数化的 XPath 接口（如果可用），或者转义用户输入以使其安全地包含在动态构造的查询中。如果您在动态构造的 XPath 查询中使用引号来终止不受信任的输入，那么您需要在不受信任的输入中转义该引号，以确保不受信任的数据无法尝试脱离该引用的上下文。在以下示例中，单引号 (’) 用于终止 Username 和 Password 参数。因此，我们需要将此输入中的任何 ’ 字符替换为该字符的 XML 编码版本，即 &apos。

String FindUserXPath;
FindUserXPath = "//Employee[UserName/text()='" + Request("Username").Replace("'", "'") 
        + "' And Password/text()='" + Request("Password").Replace("'", "'") + "']";

另一个更好的缓解选项是使用预编译的 XPath 1 查询。预编译的 XPath 查询已经在程序执行之前预设，而不是在用户输入添加到字符串后即时创建。这是一条更好的路线，因为您不必担心错过本应转义的字符

总结

本文主要介绍OWASP TOP10系列之#TOP1# 注入类，并对常见的SQL注入、CMD注入以及XPath注入简单介绍案例，仅供参考，欢迎指正~~

链接: OWASP-注入类参考链接.