首页 » 漏洞 » SQL注入测试平台:Sqli-Labs(附带使用指南-Part1)

SQL注入测试平台:Sqli-Labs(附带使用指南-Part1)

 

SQL注入测试平台:Sqli-Labs(附带使用指南-Part1)

    Sqli-Labs是一个学习SQL注入的平台,目前的测试环境覆盖了GET和POST的测试场景。

主要内容

1    Error Based Injections (Union Select)

i    String

ii    Intiger

2    Error Based Injections (Double Injection Based)

3    BLIND Injections: 1.Boolian Based 2.Time Based

4    Update Query Injection.

5    Insert Query Injections.

6    Header Injections. 1.Referer based. 2.UserAgent based. 3.Cookie based.

7    Second Order Injections

8    Bypassing WAF

i    Bypassing Blacklist filters Stripping comments Stripping OR & AND Stripping SPACES and COMMENTS Stripping UNION & SELECT

ii    Impidence mismatch

9    Bypass addslashes()

10    Bypassing mysql_real_escape_string. (under special conditions)

11    Stacked SQL injections.

12    Secondary channel extraction

Github地址:https://github.com/Audi-1/sqli-labs

使用指南(Part1)

SQL注入是一种恶意用户通过Web页面使用SQL语句注入SQL命令的技术。攻击者可以绕过用户认证和访问限制,修改、删除数据库中的数据。在某些情况下,SQL注入甚至可以用来执行操作系统级的命令,攻击者入侵内网可能带来更大的威胁。

常见的数据库类型

  • MySQL(开源)
  • MSSQL
  • MS-ACCESS
  • Oracle
  • Postgre SQL (开源)
  • SQLite

根据用于数据检索的传输信道进行分类,SQL注入可以分为:

  • In Band 【带内】:攻击者和含有漏洞个的Web应用程序之间的已有渠道来提取数据,如标准的Web服务器响应等,常见的方式有:基于Error返回的注入和基于Union查询的注入;
  • Out of Band 【带外】:使用除服务器之外的其他传输信道获取数据,如超文本传输协议或DNS解析解析等;
  • Blind SQLI【盲注】:核心是执行一系列的查询,对返回结果进行观察和推理,确认是否存在注入点,常见的方式有:布尔型注入和基于时间延迟的注入等。

SQLI注入类型

    ▪    Error Based Exploitation (基于错误返回的注入)
▪    Union Based Exploitation(基于联合查询的注入)
▪    Boolean Based Exploitation(布尔型注入)
▪    Time Based Delay Exploitation(基于时间延迟的注入)
▪    Out of Band Exploitation(带外注入)

常见的注入点:应用程序与数据库交互的地方

  • 认证页面
  • 搜索页面
  • Post请求
  • Get请求
  • HTTP头部
  • Cookie

常用的SQL语句

  • SELECT
  • INSERT
  • UPDATE
  • DELETE.
  • Order By
  • Limit By

SQL注入时常见的字符

 ‘ or “
/*…*/  (多行注释)
+
# 或者 – – (单行注释)
||
%
@ (局部变量)
@@ (全局变量)
Waiter delay ’00.00:10’
字符串替代数字,或数字替代字符串

数据库指纹

可以通过分析错误返回信息,判断数据库类型,举例如下:

SQL注入测试平台:Sqli-Labs(附带使用指南-Part1)

SQLi Lab测试平台:https://github.com/Audi-1/sqli-labs

在进行测试之前,有必要先了解一些基本的知识,比如:

数据库后台如何执行查询操作?
查询是如何形成的?
我们如何打破它?
什么是SQL注入?

以一个登录界面为例,我们被要求输入用户名和密码的信息,如:

Username — Raj
Password — Chandel

后端会执行查询,并返回一个结果。后端查询的语句类似:

SELECT * FROM table_name WHERE username=’Raj’ AND password=’Chandel’;

具体是怎么的,完全取决于程序开发者如何在SQL查询中封装参数值,可以使用单引号、双引号、或者引号和括号相结合的形式。

所以,真实的查询可能是这样的:

SELECT * FROM table_name WHERE username=’Raj’ AND password=’Chandel’;

SELECT * FROM table_name WHERE username=(’Raj’) AND password=(’Chandel’);

SELECT * FROM table_name WHERE username=”Raj” AND password=”Chandel”;

SELECT * FROM table_name WHERE username=(“Raj”) AND password=(“Chandel”);

当然了,也可能存在其他的形式,看开发人员自己的喜好和选择。

首先,以第一个查询为例:

输入:Username = Raj’

后端查询语句是:SELECT * FROM table_name WHERE username=’Raj’ ’ AND password=’Chandel’;

好像这在语法上是错误的,因为多出了一个单引号。

那么程序会自动修复这个查询吗?会如何做?

答案是肯定的,程序会查询username = Raj’,因此,SELECT * FROM table_name WHERE username=’Raj’ 这个查询将被执行。

那么剩下的查询会如何执行呢?

这就取决于后端的数据库了,一般情况下用 -+  或 # 进行拼接。

于是,上边的整个查询就可能变成了:

SELECT * FROM table_name WHERE username=’Raj’–+’ AND password=’Chandel’;

但是,我们的数据库只会读取和执行,所以在-+之后的都不会被解释为查询的一部分。

上边的例子,就是一个SQL注入,即通过恶意的输入更改后端查询的情况。

这个地方,不知道你是否会怀疑:上述这个输入,可以绕过登录验证的限制吗?

是的,如果开发人员没有采取防止SQL注入的措施,那么这个登录页面,可能只需要一个用户名就可以进入了。

感到困惑吗?  会这么幼稚?

如果你准备好了,那么请进入实验室继续学习更多复杂的利用场景吧。

 

参考来源:hackingarticles,转载请注明来自MottoIN

原文链接:SQL注入测试平台:Sqli-Labs(附带使用指南-Part1),转载请注明来源!

0