DVWA网站SQL注入的初期探索

先扫一下盲，介绍一下数字型注入和字符型注入的区别，额，其实我也是一知半解…

1、数字型注入与字符型注入

数字型注入与字符型注入的含义：
数字型注入指的是后台代码里的SQL语句里用户需要输入的值是数字，同理，字符型注入指的是用户需要输入的是字符，字符的话是以单引号闭合的。如下两个数字型注入和字符型注入的例子：

Select * from users where id = x（用户输入值）
Select * from users where id = ‘x’（用户输入值）

数字型注入判断：
当输入的参数 x 为整型时，通常 abc.php 中 Sql 语句类型大致如下： select * from <表名> where id = x 这种类型可以使用经典的 and 1=1 和 and 1=2 来判断：

Url 地址中输入 http://xxx/abc.php?id= x and 1=1 页面依旧运行正常，继续进行下一步。
Url 地址中继续输入 http://xxx/abc.php?id= x and 1=2 页面无查询结果，则说明此 Sql 注入为数字型注入。
原因如下：
当输入 and 1=1时，后台执行 Sql 语句：

select * from <表名> where id = x and 1=1 

没有语法错误且逻辑判断为正确，所以返回正常。

当输入 and 1=2时，后台执行 Sql 语句：

select * from <表名> where id = x and 1=2

没有语法错误但是逻辑判断为假，所以返回空。

字符型注入判断：
当输入的参 x 为字符型时，通常 abc.php 中 SQL 语句类型大致如下： select * from <表名> where id = ‘x’ 这种类型我们同样可以使用 and ‘1’='1 和 and ‘1’='2来判断：

Url 地址中输入 http://xxx/abc.php?id= x’ and ‘1’=‘1 页面运行正常，继续进行下一步。
Url 地址中继续输入 http://xxx/abc.php?id= x’ and ‘1’='2 查询结果返回空，则说明此 Sql 注入为字符型注入。

2、Dvwa网站实战

接下来进行dvwa网站SQL注入简单的实践：
级别：low

页面上有一个输入框，可以提交数据，这是比较典型的例子，根据我们之前说过的SQL注入步骤，我们先测试一下是否存在注入点。

最为经典的单引号判断法： 在参数后面加上单引号,比如:
http://xxx/abc.php?id=1’
如果页面返回错误，则存在 Sql 注入。 原因是无论字符型还是整型都会因为单引号个数不匹配而报错。

2.1 判断SQL注入类型

① 输入1’，点击提交

页面报错，直接给出了错误提示语句，由此，我们可以看出，网站使用的是MariaDB数据库。且存在SQL注入漏洞。
② 输入1 ，点击提交

页面正常，显示出查询结果，这不能看出什么，接着我们假设存在数字型注入，试一试1 and 1 = 1
② 输入1 and 1 = 1

③ 输入1 and 1 = 2

页面正常，没有报错，且查询出了数据，说明不存在数值型SQL注入（如果存在数值型注入，那么后台代码里要求输入的就只是数字，当我们输入1 and 1 = 2时，1=2为假，就会查询不出结果）
排除掉数值型注入！
接下来测试是否为字符型注入：
① 输入1’ and ‘1’ = '1，页面正常，可查询出信息

② 输入1’ and ‘1’ = '2，页面正常，但是没有查询出数据，因为’1’ = ‘2’为假，说明存在字符型注入漏洞。

我们基本可以确定后台的SQL语句是形如：Select * from users where id = ‘x’
因此，现在我们构造出SQL语句，使单引号闭合，查出我们想要的数据。
③ 输入1’ or ‘1’ = '1，可以查询出5条信息，成功得到表中所有的用户信息。

下面我们来看一下网站的源码，SQL语句是：
select First name的列名 and Surname的列名 from 表名 where id的列名 =‘我们输入的id’
果然是与我们想象的一样，要求输入字符，且没有过滤任何符号。

2.2 爆库、爆表…
我们现在试一下，看能不能得到数据库，查一下数据库名字
输入：1’ union select 1,database()#，查出来数据库名字为dvwa

接下来，看一下数据库里的表
输入：

`1' union select 1,table_name from information_schema.tables where table_schema='dvwa'#`

数据库的表名拿到了，一共有2个表：users和guestbook，用户表里的信息比较重要，我们看一下能爆出users表的列名么
输入：

1' union select 1,column_name from information_schema.columns where table_name='users'#

现在，查一下user和password两列的值，爆出所有的用户名和密码
输入：

1' union select 1,concat(user,password) from users#

拿到所有的用户名和密码，这个网站的SQL注入测试基本就结束了。
GAME OVER!!!

2.3 小总结

目前我们还只是执行了一些查询操作，如果是攻击者，他们可能会执行更加具有破坏性的语句，比如修改超级管理员的用户名和密码，或者执行数据库删除操作，这样会对网站造成毁灭性的破坏。

3、information_schema数据库

接着讲一讲我们在low级别SQL注入中主要用到的数据库information_schema。

在MySQL中，把 information_schema 看作是一个数据库，确切说是信息数据库。其中保存着关于MySQL服务器所维护的所有其他数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。在INFORMATION_SCHEMA中，有多个只读表。它们实际上是视图，而不是基本表，因此，你将无法看到与之相关的任何文件。

information_schema数据库表说明:

SCHEMATA[skɪˈmætə]表：提供了当前mysql实例中所有数据库的信息。命令show databases的结果取之此表。

TABLES表：提供了关于数据库中的表的信息（包括视图）。详细表述了某个表属于哪个schema，表类型，表引擎，创建时间等信息。是show tables from schemaname的结果取之此表。

COLUMNS表：提供了表中的列信息。详细表述了某张表的所有列以及每个列的信息。命令show columns from schemaname.tablename的结果取之此表。

STATISTICS表：提供了关于表索引的信息。命令show index from schemaname.tablename的结果取之此表。

USER_PRIVILEGES（用户权限）表：给出了关于全程权限的信息。该信息源自mysql.user授权表。是非标准表。

SCHEMA_PRIVILEGES（方案权限）表：给出了关于方案（数据库）权限的信息。该信息来自mysql.db授权表。是非标准表。

TABLE_PRIVILEGES（表权限）表：给出了关于表权限的信息。该信息源自mysql.tables_priv授权表。是非标准表。

COLUMN_PRIVILEGES（列权限）表：给出了关于列权限的信息。该信息源自mysql.columns_priv授权表。是非标准表。

CHARACTER_SETS（字符集）表：提供了mysql实例可用字符集的信息。是SHOW CHARACTER SET结果集取之此表。

COLLATIONS表：提供了关于各字符集的对照信息。

COLLATION_CHARACTER_SET_APPLICABILITY表：指明了可用于校对的字符集。这些列等效于SHOW COLLATION的前两个显示字段。

TABLE_CONSTRAINTS表：描述了存在约束的表。以及表的约束类型。

KEY_COLUMN_USAGE表：描述了具有约束的键列。

ROUTINES表：提供了关于存储子程序（存储程序和函数）的信息。此时，ROUTINES表不包含自定义函数（UDF）。名为“mysql.proc name”的列指明了对应于INFORMATION_SCHEMA.ROUTINES表的mysql.proc表列。

VIEWS表：给出了关于数据库中的视图的信息。需要有show views权限，否则无法查看视图信息。

TRIGGERS表：提供了关于触发程序的信息。必须有super权限才能查看该表