免责声明:文章只用于技术探讨,严厉抵制在网络搞破坏行为。
在学习Web漏洞的过程中,就一直有一个强烈的想法,试着总结一下学习的内容,另外参考了一些SQL注入漏洞挖掘实践和自身体会,寻思着写一篇思路总结。这篇文章会不断的更新,随着实践的继续和各位的指点批评会不断完善思路。
SQL注入漏洞的知识体系
一. 数据库注入:access mysql mssql oracle mongodb postgresql
不同数据库在注入上是由差异,比如:SQL语句不同,数据库的权限不一样。尤其是第二者,不同的权限衍生的思路是不一样的,有高权限和低权限之分。还有和数据库自身的配置有关。
二. 数据类型注入: 数字型 字符型 搜索型 加密型(base64 json)
在测试注入点时我们首先需要解决的问题就是数据类型,才能进一步测试注入点是否存在。
三. 提交方式注入: get post cookie http 头
提交方式决定了我们测试的注入点。一般常见的是 Get , POST 但是实际上Cookie,UA都有可能存在注入点。
四. 注入手段:堆叠,联合,报错,布尔,延时,二次注入,宽字节注入,DNS注入
网站对于SQL注入也是有防护的,我们需要采取一些手段进行绕过,以及解决一些数据不会显的问题。
溯本求源
基本的概念最能说明事物的本质,但我们将其忽略,实际上这些基本概念往往决定我们的思路。
在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的“数据”拼接到SQL语句中后,被当作SQL语句的一部分执行。 从而导致数据库受损(被脱裤、被删除、甚至整个服务器权限沦陷)。简而言之就是,由于用户不可控输入,攻击者可以任意的输入恶意的sql语句,使原始的查询语句的语义发生改变。从而对数据库或操作系统产生风险。
我们可以得到的信息:
- 用户输入的数据不可信
- SQL注入原理:黑客的payload没有经过严格检查直接拼接SQL语句后直接带入数据库执行
- SQL注入漏洞经常出现的位置:往往是一些前后端数据交互的位置,如:可以进行增删改查以及一些接口的位置。
这段信息阐述了SQL注入漏洞的原理,并且为我们寻找SQL注入漏洞提供了思路。
实战中如何寻找SQL注入漏洞
观察网页同时使用BurpSuite进行抓包,关注数据包里的参数位置,尝试修改之后,如果网页发生了变化,就很可能是这个参数被带入到数据库查询了,那么就可能存在注入点。
SQL注入点一般存在于搜索框,登录页面、查找页面或添加页面等用户可以查找或修改数据的地方。因为这里的参数值往往可能是带入了数据库查询。
我一般习惯根据功能点,看看参数的值,如果觉得这个参数可能会带入数据库查询,就很有可能存在SQL注入,直接上手SQLMap跑一下,即使不是也没损失。
其实更多还是依据实践的经验,多看看一些挖洞的文章,看看他们的姿势,结合这个本质去理解,大量积累经验才能准确的测试SQL注入漏洞。
如何测试是否存在注入点
这一步是为了测试这个位置是否存在注入点,根据原理,如果存在SQL注入漏洞,这个位置首先会被带入查询数据库,而且这个位置对恶意字符过滤不严格。
经典的单引号,因为单引号会和数字型,字符串型冲突,如果返回结果为false,就说明未被过滤,而且还被带入了数据库,即是一个注入点。
还有一些如: and 1=1 或者 and 1=2 的方法,都是这个道理。
这一步的测试需要结合数据类型,还要考虑到引号闭合的问题。
ROOT && 非ROOT
ROOT权限测试思路
可以拿MySQL举例:每个数据库都有一个用户管理,存在一个超级账户可以管理所有的数据库。
因为在代码层面上,数据库链接时设置了使用用户,这个用户的权限决定了我们的战果上限。
- 非ROOT用户:如果这个用户只是个普通用户,那么你最多只能拿下当前的数据库。
- ROOT用户:你可以进行文件读写操作,跨库查询注入等操作
MySQL && ACCESS
MYSQL5.0以上版本:自带的数据库 名为information_schema
information_schema:存储数据库下的数据库名及表名,列名信息的数据库,因为这个特性的存在,我们可以通过查询这个数据来获取表名和字段名。
-
information_schema:存储数据库下的数据库名及表名,列名信息的数据库
-
information_schema.tables:记录表名信息的表
-
information_schema.columns:记录列名信息表
ACCESS数据库
因为ACCESS的数据库是只有一个库,库下面有多个表,我们需要拿到有利用价值的表。
这里需要猜解表名,猜解字段。你可以使用字典扫描,也可以使用偏移注入。
这里仅拿出两个数据库进行举例,其它的数据库都有各自的特点,在手工注入时要因地制宜采取测略。
思考常见几种注入方式
堆叠注入:多条语句使用;隔开,基本见不到,因为这意味着网站几乎没有防护。
联合查询注入:限制条件是必须要有回显
报错注入:是sql语句的错误信息会返回给前端,这里需要有源代码中存在这条代码才行
布尔盲注:这里的网页的没有回显,但是会根据你的sql语句有true和false两种状态,常见的是网页存在于消失,可以通过状态码,网页的显示来判断
延时盲注:限制几乎没有,只需要检测数据包发出到返回间隔即可,当然因为网络因素,可能存在些许误差。
宽字节注入:适用面不广泛,与其说是注入的手法,不如说是绕过过滤的手段。
实战中测试思路
实战中并不需要我们手测,因为当今的一些工具已经很成熟了,比如SQLMap等。
所以实战中,我们主要是要找可能存在SQL注入的位置,可以简单测试一下有没有,也可以完全不测试,直接丢进SQLMap跑一跑就知道有没有。
但是并不意味着注入原理不重要,还是需要学会原理的。
SQLMap使用可以参考我得另外一篇博客:
SQLMap使用教程:从入门到入狱详细指南_貌美不及玲珑心,贤妻扶我青云志的博客-CSDN博客
也有一些别的工具也很不错,如AWVS,goby等。
之后有时间的会更新一些注入原理,手工注入等一些细节的文章。
SQL注入漏洞总结到此结束,希望路过便朋友可以的话请指点一下,或者留下你们的思考和感悟。欢迎大家在我的评论区留言。
最后的话,创作不易,求各位大佬点个赞!!!