SQL注入漏洞思路总结

  • Post author:
  • Post category:其他



免责声明:文章只用于技术探讨,严厉抵制在网络搞破坏行为。

在学习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语句,使原始的查询语句的语义发生改变。从而对数据库或操作系统产生风险。

我们可以得到的信息:

  1. 用户输入的数据不可信
  2. SQL注入原理:黑客的payload没有经过严格检查直接拼接SQL语句后直接带入数据库执行
  3. 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注入漏洞总结到此结束,希望路过便朋友可以的话请指点一下,或者留下你们的思考和感悟。欢迎大家在我的评论区留言。

最后的话,创作不易,求各位大佬点个赞!!!



版权声明:本文为qq_61553520原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。