SQL注入实战篇
2021-03-01 18:02:08 Author: www.secpulse.com(查看原文) 阅读量:240 收藏

今天要介绍的是SQL注入实验。SQL注入攻击的学习,我们更多的目的是为了学习攻击技术和防范策略,而不是刻意去攻击数据库。

首先我们先进入实验地址《SQL 注入》

SQL注入是一种代码注入技术,过去常常用于攻击数据驱动性的应用,实质就是将恶意的SQL代码注入到特定字段用于实施拖库攻击等。SQL注入的成功必须借助应用程序的安全漏洞,例如用户输入没有经过正确地过滤(针对某些特定字符串)或者没有特别强调类型的时候,都容易造成异常地执行SQL语句。SQL注入是网站渗透中最常用的攻击技术,但是其实SQL注入可以用来攻击所有的SQL数据库。以Sql注入产生的直接原因是拼凑SQL,绝大多数程序员在做开发的时候并不会去关注SQL最终是怎么去运行的,更不会去关注SQL执行的安全性,正是有了这种懒惰的程序员SQL注入一直没有消失。这种漏洞不是不可以避免,只是程序员没有这种安全意识。

对于注入漏洞来说,可能现在很多人认为它已经过时,因为这种漏洞可以被参数化查询而杜绝。以前对这种漏洞的防御方式主要有三种:

字符串检测:限定内容只能由英文、数字等常规字符,如果检查到用户输入有特殊字符,直接拒绝。但缺点是,系统中不可避免地会有些内容包含特殊字符,这时候总不能拒绝入库。

字符串替换:把危险字符替换成其他字符,缺点是危险字符可能有很多,一一枚举替换相当麻烦,也可能有漏网之鱼。

存储过程:把参数传到存储过程进行处理,但并不是所有数据库都支持存储过程。如果存储过程中执行的命令也是通过拼接字符串出来的,还是会有漏洞。

我们还是来实践吧,这样更好理解。

我们先看一下实验的大致思路

(1)找注入并确认(经典的and 1=1 and1=2)

(2)查询基本信息(数据库类型、数据库名、应用程序类型以及系统类型)

(3)查表名、字段名,拿到想查询的内容

首先我们看一下源码

1.png

这就是这一段sql查询语句造成了最常见的SQL注入。我们继续实验,这次利用到了dvwa,我们登录dvwa然后选择SQL Injection 底下难度选择low。

2.png

3.png

4.png

先进行sql注入的第一步测试是否存在sql注入漏洞。

ID等于1的时候可以正常回显

5.png

And 1=1可以正常回显

6.png

And 1=2返回错误

7.png

这里直接返回了首页,和and 1=1返回的页面不一样。这里存在SQL注入。

为什么这样就判断有sql注入了呢?原理是把测试语句代入到了数据库查询,and就是逻辑运算,1=1为真,1=2为假,所以返回不同。

好我们接下来进行第二步判断字段数,order by 2返回正常order by 3返回错误。

8.png

字段数已经判断出来,下面如何进一步判断数据库名和用户名等基本信息。

利用语句查询知道有两个字段,接着查询数据库名和用户。

查询数据库等基本信息。

UNION SELECT 1,CONCAT_WS(CHAR(32,58,32),user(),database(),version())

9.png

这是直接返回了数据库的usr database version。我们知道数据库的名字不就可以利用查询语句找到表的名字。

查询表段

union select 1,table_name from information_schema.tables where table_schema=0x64767761(数据库的十六进制)

10.png

查询列名

union select 1,column_name from information_schema.columns where table_name=0x7573657273(表的十六进制) and table_schema=0x64767761(数据库的十六进制)

11.png

查询用户名密码

union select password,user from users

12.png

这就把用户名跟密码爆出来了。

sql注入还不止这点,还有很多类型:

1)注入分为哪几种类型?分类依据是什么?是否唯一?

2)普通注入和盲注的区别是什么?利用方法有什么不同?

本次的实验就介绍到这里,注意多加总结和思考课后问题!我们学习的目的除了了解之外,更重要的是学习如何防范SQL注入。在面对SQL注入攻击的时候,了解其原理才能更好的防范。

下面总结几点防范SQL注入攻击的要点:

1.永远不要信任用户的输入,要对用户的输入进行校验,可以通过正则表达式,或限制长度,对单引号和双"-"进行转换等。

2.永远不要使用动态拼装SQL,可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。

3.永远不要使用管理员权限的数据库连接,为每个应用使用单独的权限有限的数据库连接。

4.不要把机密信息明文存放,请加密或者hash掉密码和敏感的信息。

5.应用的异常信息应该给出尽可能少的提示,最好使用自定义的错误信息对原始错误信息进行包装,把异常信息存放在独立的表中。

本文作者:蚁景科技

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/153899.html


文章来源: https://www.secpulse.com/archives/153899.html
如有侵权请联系:admin#unsafe.sh