OWASPTOP10之注入

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

注入漏洞的攻击向量

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

产生注入漏洞的原因

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

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

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

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

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

常见的注入方式

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

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

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

        首先试探下输入ID数字2&＃xff0c;显然可以获取到用户名&＃xff1b;

        接下来试探下屡试不爽的or语句3&＃39; or &＃39;1&＃39;&＃61;&＃39;1&＃xff0c;可以看到&＃xff0c;显然是拿到了全部的账号信息&＃xff0c;目的达成。

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

如何预防注入

1、对特殊的查询字符进行转移&＃xff1b;

2、尽可能使用白名单进行输入验证&＃xff1b;

3、在系统中考虑所有事件类型和入口点&＃xff1b;

4、标识信任源和资源并将其添加进白名单&＃xff1b;

5、赋予执行函数最小特权&＃xff0c;以此减少攻击面&＃xff1b;

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