OWASP-TOP10 之 注入

        注入，汉语解释为泵入、灌入或流入。站在应用程序的角度来说就是输入，如果这个输入是恶意的，并且应用程序并未判断为无效输入或者说并未进行拦截和过滤，这时候注入漏洞就出现了，OWASP的官方解释可以见这里，http://www.owasp.org/index.php/Injection_Flaws。

注入漏洞的攻击向量

        在概述中我就有描述过攻击向量，用来描述攻击者的攻击路径（方法），那么注入的攻击向量是什么呢？一般指的是恶意攻击者可以进行控制或者进行输入的每一个地方。注入漏洞一般会出现在SQL、LDAP、XPath、NoSQL的查询语句中，同样也会存在于OS命令、XML解析器、SMTP包头、表达式语句以及ORM查询语句中。

产生注入漏洞的原因

        注入漏洞的根本原因，我的理解是当攻击者向应用程序发送恶意数据的时候，应用程序并未进行校验，直接传递给到解释器，解释器是不会对攻击者输入的恶意数据进行校验，而是直接翻译成机器可以执行的语句，于是乎攻击者的目的便达成了。常见的产生注入漏洞的原因如下：

1、应用程序未对用户的数据输入做任何的验证、过滤；

2、动态查询语句或非参数化 的调用，在没有上下文感知转义的情况下，被用于解释器；

3、在ORM搜索参数中使用了恶意数据，这样搜索就获得包含敏感或未授权的数据；

4、恶意数据直接被使用或连接，诸如SQL语句或命令在动态查询语句、命令或存储过程中包含结构和恶意数据；

常见的注入方式

名称	注入方式
OS注入	在应用程序获取用户输入的地方输入可执行的系统命令来获取服务器权限；
SQL注入	在应用程序已定义好的SQL语句后面通过某些特殊的符号增加额外的语句实现攻击；
NoSQL注入	输入非SQL语句，如系统操作命令等来实现攻击的目的；
LDAP注入	输入简单的LDAP语句来自动补全过滤器，以达到提权或绕过验证；
XML解析器	通过DTD、XPath的方式，通过尝试访问内网文件的方式实现；
SMTP包头注入	邮件头注入，通过修改发包，加入CC（抄送人）等方式获取信息
ORM查询注入	通过注入拼接过的sql代码进行注

        除了上面的这些名字上就带注入的方式，反序列化漏洞的利用，我认为也可以归属到注入这个大类里面，比如Shiro反序列化漏洞、fastjson1.2.47漏洞（大家可以看我前面的文章，有详细的讲解利用方法和利用原理）。

        上面是我用dvwa搭建的一个存在sql注入漏洞的靶机环境，下面是被注入页面的源码。

        可以看到源码中对用户传来的id值并没有做任何的校验过滤，显然存在sql注入漏洞的。（这里我只做一个简单的示例，接下来会针对sql注入单独出一篇文章。）

        首先试探下输入ID数字2，显然可以获取到用户名；

        接下来试探下屡试不爽的or语句3' or '1'='1，可以看到，显然是拿到了全部的账号信息，目的达成。

        我们简单的来说下为什么输入or后面那一串能实现的，可以注意到，源码里面有一句SQL语句，我们在输入框中输入的数据将会传递给到上面这句话的$id，我们尝试将我的恶意输入代入，如下图所示，因为没有对我的输入进行判断，所以将or这个词也带进select语句里面了，后面的1=1显然为真，所以，对于判断语句WHERE而言，就是输出全部的first_name和last_name，由此，便实现了SQL注入，如今这类的洞是少之又少了，但是根据这个逻辑，还是有不少类似的SQL注入漏洞的。

如何预防注入

1、对特殊的查询字符进行转移；

2、尽可能使用白名单进行输入验证；

3、在系统中考虑所有事件类型和入口点；

4、标识信任源和资源并将其添加进白名单；

5、赋予执行函数最小特权，以此减少攻击面；

6、使用安全的API，避免使用解释器，或者提供参数化界面的接口，或迁移到ORM或实体框架；