pikachu靶场SQL基础知识大全集

1、什么是SQL注入

SQL注入是一种网络攻击技术，它利用应用程序对用户输入数据的处理不当，从而使攻击者能够执行恶意的SQL查询或命令。通过成功利用SQL注入漏洞，攻击者可以绕过应用程序的安全验证，访问、修改或删除数据库中的数据，甚至执行系统级命令。

SQL注入通常发生在使用结构化查询语言（SQL）与数据库进行交互的Web应用程序中。这类应用程序通常接受用户输入，将其嵌入到SQL查询语句中，然后将查询发送到数据库执行。然而，如果应用程序没有正确地验证、转义或过滤用户输入，攻击者可以利用这个漏洞注入恶意的SQL代码。

攻击者利用SQL注入的目的包括：

绕过认证：攻击者可以通过注入特定的SQL代码来绕过应用程序的登录验证，以获得未经授权的访问权限。

数据泄露：攻击者可以构造恶意的SQL查询，以获取应用程序数据库中的敏感数据，如用户信息、账户凭证或其他机密数据。

数据篡改：攻击者可以修改数据库中的数据，包括插入、更新或删除记录，从而破坏数据的完整性或更改应用程序的行为。

服务器攻击：通过在SQL注入中执行系统级命令，攻击者可以控制服务器，执行恶意操作或进一步渗透网络。

2、SQL注入的产生

SQL注入产生的原因主要是应用程序对用户输入数据的处理不当，导致攻击者能够插入恶意的SQL代码。以下是一些常见的导致SQL注入漏洞的原因：

不正确的输入验证与过滤：应用程序在接收用户输入之前，未进行充分的验证和过滤。没有对输入数据进行验证，确保其符合预期的格式、长度和类型。同时，没有对输入数据进行适当的过滤，未排除或转义潜在的恶意字符或代码。

动态拼接SQL语句：应用程序在构建SQL查询时，可能使用动态拼接的方式将用户输入直接插入到查询语句中。这种做法存在风险，因为攻击者可以通过插入恶意的SQL代码来改变原始查询的含义。

缺乏参数化查询：应用程序未使用参数化查询（也称为预编译语句）来构建SQL查询。参数化查询可以将用户输入作为查询参数传递，而不是将其直接插入到查询语句中。缺乏参数化查询的应用程序容易受到SQL注入攻击。

不安全的数据库权限：数据库用户被授予了过高的权限，使得攻击者在成功注入恶意代码后能够执行危险的操作。如果数据库用户具有对敏感数据表的写入权限，或者可以执行系统级命令，那么SQL注入攻击的后果将更为严重。

不完善的错误处理机制：应用程序在处理数据库错误或异常时，可能泄露敏感的错误信息，如具体的SQL查询语句或数据库结构。攻击者可以利用这些信息来发现潜在的注入点并进一步利用漏洞。

缺乏安全意识和培训：开发人员缺乏对SQL注入漏洞的认识和理解，没有接受过相关的安全培训。这可能导致他们在编写代码时忽略了关键的安全性原则和最佳实践。

3、SQL注入原理

SQL注入是一种利用应用程序对用户输入的处理不当而进行的攻击。它利用了数据库查询语言（SQL）的特性和应用程序的漏洞，通过插入恶意的SQL代码来执行未经授权的操作。

SQL注入攻击的原理可以分为以下几个步骤：

1.用户输入：Web应用程序通常接收用户的输入，例如通过表单、URL参数或其他方式。攻击者利用这些输入字段将恶意的SQL代码插入到应用程序中。

2.构造恶意查询：应用程序接收到用户输入后，会将其嵌入到SQL查询语句中。如果应用程序没有对输入进行正确的验证、过滤或转义，恶意的SQL代码将会被构造并包含在最终生成的查询语句中。

3.注入恶意代码：攻击者的目标是通过注入恶意的SQL代码来改变原始的查询语句的含义或执行其他操作。他们可以利用各种注入点，如用户认证、搜索功能、登录表单、排序参数等。通过构造特定的输入，攻击者可以干扰查询的逻辑，绕过应用程序的安全机制。

4.攻击操作：一旦恶意代码成功注入并执行，攻击者可以实现多种操作。这包括但不限于数据泄露、数据修改、数据删除、系统命令执行等。攻击者可以利用SQL注入漏洞来访问或修改他们未经授权的数据，进而危害应用程序和数据库的安全性。

下面是一个简单的示例，展示了一个容易受到SQL注入攻击的登录查询：

SELECT * FROM users WHERE username = '$usernam{e}^{\prime }ANDpassword{=}^{\prime }$password'

在上述查询中，$username和$password是通过用户输入传递的变量。如果应用程序没有对这些输入进行正确的处理，攻击者可以构造恶意的输入来注入SQL代码。例如，攻击者可以在用户名字段中输入' OR '1'='1，使得最终的查询语句变为：

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '$password'

这样的查询条件永远为真，绕过了用户名和密码的验证，导致攻击者可以成功登录而不需要正确的凭证。

为了防止SQL注入攻击，开发人员应该采取安全的编码实践，包括输入验证与过滤、参数化查询、最小权限原则和定期安全审计等措施。

4、SQL注入攻击

下面是一个简单的SQL注入攻击示例，假设有一个登录表单，用户需要输入用户名和密码进行认证。

原始查询语句如下：

SELECT * FROM users WHERE username = '$usernam{e}^{\prime }ANDpassword{=}^{\prime }$password'

攻击者可以在用户名或密码字段中注入恶意的SQL代码，以绕过身份验证并获取未经授权的访问权限。

示例1：绕过身份验证

假设攻击者在用户名字段中输入' OR '1'='1，构造的查询语句如下：

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '$password'

这个查询条件始终为真，绕过了实际的用户名验证，使攻击者可以成功登录到系统中。

示例2：注入恶意条件

攻击者可以在用户名或密码字段中注入恶意的SQL代码，以执行其他操作或获取敏感信息。例如，攻击者输入' OR 1=1; --，构造的查询语句如下：

SELECT * FROM users WHERE username = '' OR 1=1; --' AND password = '$password'

注释符号用来注释掉原始查询语句的剩余部分，使得查询将返回所有用户的记录，忽略了密码验证，因此攻击者可以获取所有用户的信息。

4.1、POST与GET

在SQL漏洞扫描时，POST方式和GET方式是两种常见的HTTP请求方法，以下是POST方式和GET方式的区别：

数据传输方式：

1.GET方式：GET请求将参数以查询字符串的形式附加在URL的末尾，例如    http://example.com/page?param1=value1¶m2=value2    参数直接暴露在URL中，可以被拦截、记录或缓存。

2.POST方式：POST请求将参数包含在请求体中，而不是在URL中。参数不可见，不会直接暴露在URL中。

参数位置：

1.GET方式：参数直接附加在URL中，可在URL的查询字符串中找到。

2.POST方式：参数包含在请求体中，通过HTTP消息体传输。

安全性：

1.GET方式：由于参数直接暴露在URL中，可能会被恶意拦截、修改或记录，因此安全性较低。敏感信息如密码等不应该通过GET方式传输。

2.POST方式：参数不直接暴露在URL中，相对更安全。敏感信息可以通过POST方式进行传输，减少了泄露风险。

在SQL漏洞扫描时，POST方式和GET方式在扫描过程中的使用和处理会因为其特性而略有不同：

GET方式：漏洞扫描工具通常会通过修改URL中的参数值来测试是否存在SQL注入漏洞。它会构造不同的恶意输入并发送GET请求，观察应用程序的响应以检测潜在的漏洞。

POST方式：漏洞扫描工具会将恶意输入作为POST请求的参数，并将其放置在请求体中，然后发送POST请求，检查应用程序的响应以判断是否存在SQL注入漏洞。

4.2、GET请求与POST请求

在Python中，使用requests库可以发送GET和POST请求。这个库提供了用于与Web服务器进行HTTP通信的API。

GET请求示例：

import requests

# 发送GET请求

response = requests.get('url')# 获取响应内容

# 处理响应数据

data = response.text

print(data)

POST请求示例：

import requests

# 发送POST请求

payload = {'key1': 'value1', 'key2': 'value2'}

# 获取响应内容

response = requests.post('url', data=payload)data =

# 处理响应数据

response.text

print(data)

在GET请求示例中，使用requests.get函数发送GET请求，传递URL作为参数。

在POST请求示例中，使用requests.post函数发送POST请求，并传递URL和请求数据作为参数。

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

在SQL漏洞扫描中，数字型注入和字符型注入是两种不同类型的SQL注入漏洞。它们在注入点和注入方式上略有不同。

数字型注入：

注入点：数字型注入通常发生在应用程序将用户输入直接用作SQL查询中的数字值时。例如，通过URL参数、表单输入等将数字值传递给SQL查询。

注入方式：攻击者尝试在数字值的注入点中注入恶意的SQL代码，通常使用数字相关的操作符和函数来构造注入语句。

示例：在数字型注入中，攻击者可能会尝试通过输入1 OR 1=1或1; DROP TABLE users来改变原始查询的逻辑，绕过验证或执行其他操作。

字符型注入：

注入点：字符型注入通常发生在应用程序将用户输入直接用作SQL查询中的字符串值时。例如，通过URL参数、表单输入等将字符串值传递给SQL查询。

注入方式：攻击者尝试在字符串值的注入点中注入恶意的SQL代码，通常使用字符串相关的操作符和特殊字符来构造注入语句。

示例：在字符型注入中，攻击者可能会尝试通过输入' OR '1'='1或' UNION SELECT * FROM users--来改变原始查询的逻辑，绕过验证或获取敏感数据。

区别：

注入点：数字型注入和字符型注入发生在不同类型的输入点。数字型注入通常发生在应用程序将用户输入作为数字值的情况下，而字符型注入发生在字符串值的情况下。

注入方式：数字型注入和字符型注入使用不同的操作符和函数来构造恶意的SQL代码。数字型注入通常使用数字相关的操作符，而字符型注入使用字符串相关的操作符和特殊字符。

影响范围：由于注入点和注入方式的不同，数字型注入和字符型注入可能会对不同的查询和数据库对象产生不同的影响。

4.4、insert/update/delete注入

INSERT注入：

Payload示例：假设有一个简单的INSERT查询，向users表中插入用户名和密码的语句：

INSERT INTO users (username, password) VALUES ('$usernam{e}^{\prime }{,}^{\prime }$password')

在注入攻击中，攻击者可以构造恶意的用户名和密码，通过注入来修改或插入其他数据：

username: 'admin'); --

password: 'password'

攻击者在用户名中注入 'admin'); --，这会导致原始查询变为：

INSERT INTO users (username, password) VALUES ('admin'); --', 'password')

回显：由于INSERT查询通常不会直接回显结果，攻击者无法直接获取回显信息。但他们可以通过其他手段判断注入是否成功，例如观察是否有新的数据插入到目标表中。

UPDATE注入：

Payload示例：假设有一个简单的UPDATE查询，更新users表中密码的语句：

UPDATE users SET password = '$ne{w}_{p}asswor{d}^{\prime }WHEREusername{=}^{\prime }$username'

在注入攻击中，攻击者可以通过注入来修改或删除数据，例如：

username: 'admin'; DROP TABLE users --

new_password: 'new_password'

攻击者在用户名中注入 'admin'; DROP TABLE users --，这会导致原始查询变为：

UPDATE users SET password = 'new_password' WHERE username = 'admin'; DROP TABLE users --

回显：与INSERT注入类似，UPDATE查询通常不会直接回显结果。攻击者需要通过其他方式判断注入是否成功。

DELETE注入：

Payload示例：假设有一个简单的DELETE查询，从users表中删除用户的语句：

DELETE FROM users WHERE username = '$username'

在注入攻击中，攻击者可以通过注入来删除指定的数据，例如：

username: 'admin'; DROP TABLE users --

攻击者在用户名中注入 'admin'; DROP TABLE users --，这会导致原始查询变为：

DELETE FROM users WHERE username = 'admin'; DROP TABLE users --

回显：与INSERT和UPDATE注入类似，DELETE查询通常不会直接回显结果。攻击者需要通过其他方式判断注入是否成功。

4.5、HTTP Header注入

HTTP头注入（HTTP Header Injection）是一种针对Web应用程序的安全漏洞，攻击者通过在HTTP请求的头部中注入恶意内容来进行攻击。这种注入漏洞可能导致包括跳过身份验证、执行恶意操作、重定向攻击在内的多种安全问题。

HTTP头注入的原理： HTTP头注入通常发生在应用程序接收用户输入并将其包含在HTTP响应头中的情况下。攻击者利用未正确过滤或转义用户输入的情况，通过在输入中注入特殊字符来修改响应头的内容，进而实现攻击目的。

Payload示例： 攻击者可以通过在用户输入中注入特殊字符来触发HTTP头注入漏洞，例如换行符（\r\n）或换行符的URL编码形式（%0D%0A）。

payload：

User-Agent:

Mozilla/5.0\r\nLocation:http://malicious-site.com\r\n\r\n

攻击者将恶意的HTTP头作为用户输入的一部分，注入到请求中。上述payload中，攻击者在User-Agent字段中使用\r\n换行符，然后添加自定义的Location字段和值，最后以两个换行符结束。

回显： HTTP头注入的回显通常体现在响应中，因为攻击者通过修改HTTP响应头来实现攻击目的。例如，在上述示例中，如果应用程序未正确处理并过滤用户输入，攻击者注入的恶意头部会被包含在服务器的HTTP响应中。这样，攻击者可以观察到服务器返回的响应，以验证注入是否成功。

 

4.6、时间盲注和布尔盲注

时间盲注（Time-Based Blind Injection）和布尔盲注（Boolean-Based Blind Injection）是SQL注入的两种常见类型，它们用于在无法直接获取查询结果的情况下，通过观察应用程序的行为或延迟来推断查询结果。

时间盲注（Time-Based Blind Injection）：

时间盲注是在注入点中注入恶意SQL代码，并利用延迟等待来判断查询的执行情况。

Payload示例：假设有一个简单的查询，判断某个条件是否成立：

SELECT * FROM users WHERE username = 'admin' AND IF(条件成立, SLEEP(5), 0)

攻击者可以通过在条件中注入恶意代码，来观察应用程序是否有延迟等待的情况，例如：

username: 'admin' AND IF(条件成立, SLEEP(5), 0)

回显：攻击者无法直接获取查询结果，但可以观察应用程序是否在查询条件成立时产生延迟等待，从而推断出查询的结果。

布尔盲注（Boolean-Based Blind Injection）：

布尔盲注是在注入点中注入恶意SQL代码，并观察应用程序的行为或错误信息来推断查询的结果。

Payload示例：假设有一个简单的查询，判断某个条件是否成立：

SELECT * FROM users WHERE username = 'admin' AND (条件成立)

攻击者可以通过在条件中注入恶意代码，观察应用程序的行为来推断查询的结果，例如：

username: 'admin' AND (条件成立)

回显：攻击者观察应用程序在查询条件成立时的不同行为或错误信息，例如返回的页面内容、错误消息的差异等，以推断出查询的结果。

4.7、宽字节注入

宽字节注入（Wide-Character Injection）是一种针对某些数据库和编码方式的特定类型的SQL注入攻击。宽字节注入通常发生在应用程序没有正确处理和转义特殊字符时，特别是在使用较旧的版本的MySQL数据库和GBK编码时。

宽字节注入（Wide-Character Injection）：

宽字节注入利用某些编码方式（如GBK）中的特殊字符编码规则，通过在用户输入中插入宽字符来绕过输入过滤和验证，从而执行恶意的SQL语句。

Payload示例：在宽字节注入中，攻击者会在用户输入中插入带有特殊编码的宽字符，例如在GBK编码中，将单引号 ' 转换为 %bf%27：

username: admin%bf%27 OR 1=1 --

回显：回显的方式与普通的SQL注入类似，攻击者可以观察应用程序的响应或错误消息，以推断查询是否执行成功或产生异常行为。