天天最新:SQL注入語義分析庫libinjection簡介
目錄
SQL注入語義分析庫libinjection什么是libinjectionlibinjection和正則表達式modsecurity 如何使用libinjectionModSecurity只用了libinjection防御sql注入嗎?WAF研發(fā)領域,語義分析相對于正則表達式先進性的研究參考文獻SQL注入語義分析庫libinjection
什么是libinjection
libinjection是一款用于防御SQL注入攻擊的開源軟件庫。它是由C語言編寫的,可以嵌入到任何Web應用程序中,并可以較為準確地檢測和防止惡意SQL注入語句。libinjection采用了基于正則表達式的技術(shù)來識別和攔截SQL注入攻擊,同時其開放源代碼的特點也使得其具備了較高的可定制性和擴展性。
libinjection是一個基于C語言的SQLi詞法解析分析器,它可以通過對不同語句進行詞法分析和語法分析來實現(xiàn)對SQL語句以及HTML語句的解析。
(相關資料圖)
在此之前,市場上絕大多數(shù)的WAF都是基于正則匹配(Regex)的,很多的WAF(防火墻)以及NGWAF(下一代防火墻)出于性能方面的考慮,都會選擇使用這個庫來代替常規(guī)的正則表達式。
ModSecurity,它是Apache和nginx的流行WAF。ModSecurity捆綁了libinjection,mod_security從2.7.4版本開始就支持libinjection(dectectSQLi-v2.7.4、detectXSS-v2.8.0)。
libinjection和正則表達式
libinjection和正則表達式都是非常有效的防御SQL注入攻擊的技術(shù),但兩者之間有一些差異和優(yōu)劣。
libinjection
libinjection是一個專門用于檢測SQL注入攻擊的庫,其使用了一個基于機器學習的算法來分析請求中的SQL語句。與正則表達式相比,它有以下優(yōu)點:
正則表達式
正則表達式是一種常見的用于檢測和防御各種Web應用程序攻擊(包括SQL注入攻擊)的技術(shù)。與libinjection相比,它有以下優(yōu)點:
更通用:正則表達式不僅可用于檢測SQL注入攻擊,而且還可用于檢測其他類型的Web應用程序攻擊。更靈活:正則表達式可以使用各種模式和操作符,從而可以靈活地處理各種復雜情況。更可配置性:正則表達式的規(guī)則庫可以根據(jù)實際情況進行定制和配置。
總體而言,libinjection可能比正則表達式更準確,更容易維護,并具有更快的性能,但正則表達式更通用,更靈活,具有更高的可配置性。因此,為了獲得最佳的安全性能,您可能需要考慮同時使用這兩種技術(shù)。
modsecurity 如何使用libinjection
下面是使用libinjection和ModSecurity進行SQL注入檢測和預防的步驟:
安裝ModSecurity
安裝并配置ModSecurity,使其可以與您的Web服務器一起使用。
安裝libinjection
安裝libinjection并將其與ModSecurity集成。如果您使用的是Debian或Ubuntu,可以使用以下命令進行安裝:
sudo apt-get install libinjection-dev
在ModSecurity中使用libinjection
將ModSecurity配置為使用libinjection來檢測SQL注入攻擊。以下是一個示例ModSecurity規(guī)則,可用于檢測SQL注入攻擊:
SecRule ARGS "@detectSQLi" \
"id:1,\
phase:2,\
t:none,\
t:lowercase,\
t:replaceComments,\
t:compressWhitespace,\
ctl:auditLogParts=+E,\
ctl:debugLogParts=+E,\
ctl:requestBodyProcessor=XML,\
ctl:ruleEngine=on,\
ctl:auditEngine=on,\
ctl:ruleRemoveByTag=abcd \
ctl:ruleRemoveById=1 \
libinjection_check"
SecRule &TX:INJECTION @eq 1 \
"id:2,\
phase:2,\
t:none,\
ctl:auditLogParts=+E,\
ctl:debugLogParts=+E,\
ctl:requestBodyProcessor=XML,\
ctl:ruleEngine=on,\
ctl:auditEngine=On,\
ctl:ruleRemoveByTag=abcd \
ctl:ruleRemoveById=2 \
block"這個規(guī)則中包含了兩個SecRule。第一個將對輸入請求進行規(guī)范化和過濾,然后使用libinjection檢測SQL注入攻擊。第二個SecRule將根據(jù)檢測結(jié)果來做出相應的動作,例如阻止訪問請求或?qū)⑵溆涗浽谌罩局小?/p>
ModSecurity只用了libinjection防御sql注入嗎?
ModSecurity不僅使用了libinjection,還使用了正則表達式等多種技術(shù)來進行SQL注入攻擊防御。實際上,在ModSecurity中使用正則表達式是非常常見的一種方法,因為這種方法可以用于檢測和阻止各種類型的Web應用程序攻擊,包括SQL注入攻擊。
以下是一個示例ModSecurity規(guī)則,使用正則表達式檢測SQL注入攻擊:
SecRule ARGS "@detectSQLi" \
"id:1,\
phase:2,\
t:none,\
t:lowercase,\
t:replaceComments,\
t:compressWhitespace,\
ctl:auditLogParts=+E,\
ctl:debugLogParts=+E,\
ctl:requestBodyProcessor=XML,\
ctl:ruleEngine=on,\
ctl:auditEngine=on,\
ctl:ruleRemoveByTag=abcd \
ctl:ruleRemoveById=1 \
libinjection_check"
SecRule &TX:INJECTION @eq 1 \
"id:2,\
phase:2,\
t:none,\
ctl:auditLogParts=+E,\
ctl:debugLogParts=+E,\
ctl:requestBodyProcessor=XML,\
ctl:ruleEngine=on,\
ctl:auditEngine=On,\
ctl:ruleRemoveByTag=abcd \
ctl:ruleRemoveById=2 \
block"雖然語義分析引擎能夠更準確地識別和阻止惡意流量,但是正則表達式仍然是一種非常重要的檢測方式,可以用來完成一些特定的任務。
例如,對于某些規(guī)則化的數(shù)據(jù)格式,如郵件地址、電話號碼和身份證號碼等,使用正則表達式可以快速、準確地進行匹配判斷。此外,正則表達式還可以用來檢測各種類型的注入攻擊(如SQL注入和XSS攻擊)等漏洞利用行為。
因此,在實際的安全防御中,WAF通常會同時采用多種技術(shù)手段,包括語義分析引擎和正則表達式等,以提高其檢測能力,并最大程度地保護Web應用程序免受攻擊威脅。
WAF研發(fā)領域,語義分析相對于正則表達式先進性的研究
多年以來,WAF對攻擊的檢測,通常使用正則表達式,典型的如ModSecurity。作為老牌的WAF,其擁有龐大的正則規(guī)則庫。其檢測率高,但也正因為規(guī)則數(shù)量龐大,正則逐一匹配,此過程速度慢,性能低。
對于同步檢測的WAF產(chǎn)品,部署并對網(wǎng)站提供防護后,會帶來不小的訪問性能影響。
新興的WAF產(chǎn)品,漸有使用語義分析引擎取代正則表達式檢測。
其優(yōu)勢究竟何在,性能又能提升多少?
WAF研發(fā)領域,語義分析相對于正則表達式先進性的研究
直接查看原文鏈接: https://www.toutiao.com/article/6944906084217799207/
libinjection架構(gòu)和使用
官方使用示例
#include#include #include "libinjection.h" int main(int argc, const char* argv[]) { char fingerprint[8]; const char* input; size_t slen; int issqli; if (argc < 2) { fprintf(stderr, "Usage: %s inputstring\n", argv[0]); return -1; } input = argv[1]; slen = strlen(input); issqli = libinjection_sqli(input, slen, fingerprint); if (issqli) { printf("sqli with fingerprint of "%s"\n", fingerprint); } else { printf("not sqli\n"); } return issqli; }
具體的檢查sql注入實現(xiàn)為 libinjection_is_sqli:
int libinjection_is_sqli(struct libinjection_sqli_state * sql_state)
{
const char *s = sql_state->s;
size_t slen = sql_state->slen;
/*
* no input? not SQLi
*/
if (slen == 0) {
return FALSE;
}
/*
* test input "as-is"
*/
libinjection_sqli_fingerprint(sql_state, FLAG_QUOTE_NONE | FLAG_SQL_ANSI);
if (sql_state->lookup(sql_state, LOOKUP_FINGERPRINT,
sql_state->fingerprint, strlen(sql_state->fingerprint))) {
return TRUE;
} else if (reparse_as_mysql(sql_state)) {
libinjection_sqli_fingerprint(sql_state, FLAG_QUOTE_NONE | FLAG_SQL_MYSQL);
if (sql_state->lookup(sql_state, LOOKUP_FINGERPRINT,
sql_state->fingerprint, strlen(sql_state->fingerprint))) {
return TRUE;
}
}
/*
* if input has a single_quote, then
* test as if input was actually "
* example: if input if "1" = 1", then pretend it"s
* ""1" = 1"
* Porting Notes: example the same as doing
* is_string_sqli(sql_state, """ + s, slen+1, NULL, fn, arg)
*
*/
if (memchr(s, CHAR_SINGLE, slen)) {
libinjection_sqli_fingerprint(sql_state, FLAG_QUOTE_SINGLE | FLAG_SQL_ANSI);
if (sql_state->lookup(sql_state, LOOKUP_FINGERPRINT,
sql_state->fingerprint, strlen(sql_state->fingerprint))) {
return TRUE;
} else if (reparse_as_mysql(sql_state)) {
libinjection_sqli_fingerprint(sql_state, FLAG_QUOTE_SINGLE | FLAG_SQL_MYSQL);
if (sql_state->lookup(sql_state, LOOKUP_FINGERPRINT,
sql_state->fingerprint, strlen(sql_state->fingerprint))) {
return TRUE;
}
}
}
/*
* same as above but with a double-quote "
*/
if (memchr(s, CHAR_DOUBLE, slen)) {
libinjection_sqli_fingerprint(sql_state, FLAG_QUOTE_DOUBLE | FLAG_SQL_MYSQL);
if (sql_state->lookup(sql_state, LOOKUP_FINGERPRINT,
sql_state->fingerprint, strlen(sql_state->fingerprint))) {
return TRUE;
}
}
/*
* Hurray, input is not SQLi
*/
return FALSE;
}
這段代碼是用于檢測 SQL 注入攻擊的,通過調(diào)用 libinjection 庫對輸入的 SQL 查詢語句進行指紋識別,并判斷是否存在于已知的 SQL 注入指紋庫中。
首先獲取輸入字符串 s 和其長度 slen。如果輸入字符串長度為0,則直接返回 FALSE,不需要進行檢測。接著,對輸入的 SQL 查詢語句進行指紋識別,并標記 FLAG_QUOTE_NONE 和 FLAG_SQL_ANSI 標志位。然后通過 sql_state->lookup 函數(shù)查找該指紋是否已經(jīng)存在于數(shù)據(jù)庫中,如果存在則返回 TRUE。“test input as-is” 的意思是對輸入的 SQL 語句進行原樣測試,即不進行任何轉(zhuǎn)義或處理。這相當于將輸入的 SQL 語句作為一個整體進行指紋識別,并標記 FLAG_QUOTE_NONE 和 FLAG_SQL_ANSI 標志位,在已知的 SQL 注入指紋庫中查找是否存在相同的指紋。如果存在,則說明該輸入可能是 SQL 注入攻擊,否則繼續(xù)進行其他檢測。通常情況下,如果輸入字符串包含單引號或雙引號字符或者 SQL 關鍵字,就需要進行進一步的檢測和處理。
如果該指紋不存在于數(shù)據(jù)庫中,則嘗試將查詢語句解析為 MySQL 語法,通過 reparse_as_mysql 函數(shù)進行轉(zhuǎn)換。如果轉(zhuǎn)換成功,則再次調(diào)用 libinjection_sqli_fingerprint 函數(shù)對轉(zhuǎn)換后的 SQL 查詢語句進行指紋識別,并標記 FLAG_QUOTE_NONE 和 FLAG_SQL_MYSQL 標志位。最后再次通過 sql_state->lookup 函數(shù)查找該指紋是否存在于數(shù)據(jù)庫中,如果存在則返回 TRUE。接下來,如果輸入的字符串中包含單引號字符,則調(diào)用 libinjection_sqli_fingerprint 函數(shù)對 SQL 查詢語句進行指紋識別,并標記 FLAG_QUOTE_SINGLE 和 FLAG_SQL_ANSI 標志位。然后通過 sql_state->lookup 函數(shù)查找該指紋是否已經(jīng)存在于數(shù)據(jù)庫中,如果存在則返回 TRUE。如果該指紋不存在于數(shù)據(jù)庫中,則嘗試將查詢語句解析為 MySQL 語法,通過 reparse_as_mysql 函數(shù)進行轉(zhuǎn)換。如果轉(zhuǎn)換成功,則再次調(diào)用 libinjection_sqli_fingerprint 函數(shù)對轉(zhuǎn)換后的 SQL 查詢語句進行指紋識別,并標記 FLAG_QUOTE_SINGLE 和 FLAG_SQL_MYSQL 標志位。最后再次通過 sql_state->lookup 函數(shù)查找該指紋是否存在于數(shù)據(jù)庫中,如果存在則返回 TRUE。最后,如果輸入的字符串中包含雙引號字符,則調(diào)用 libinjection_sqli_fingerprint 函數(shù)對 SQL 查詢語句進行指紋識別,并標記 FLAG_QUOTE_DOUBLE 和 FLAG_SQL_MYSQL 標志位。然后通過 sql_state->lookup 函數(shù)查找該指紋是否已經(jīng)存在于數(shù)據(jù)庫中,如果存在則返回 TRUE。如果輸入字符串沒有被識別為 SQL 注入攻擊,則最后返回 FALSE。總結(jié),這段代碼是用于檢測 SQL 注入攻擊,通過指紋識別技術(shù)來進行檢測和防御。同時支持 ANSI SQL 和 MySQL 兩種語法,并能夠檢測包含單引號和雙引號字符以及 SQL 關鍵字的字符串。
例如,輸入常用的SQL注入的檢測語句 :’ and 1=1
libinjection會將其轉(zhuǎn)換為s&1,其中單引號依據(jù)定義被轉(zhuǎn)換為s,and被轉(zhuǎn)換為&,數(shù)字被轉(zhuǎn)換為1。
libinjection在轉(zhuǎn)換完后,通過二分查找算法對內(nèi)置的特征進行匹配,匹配到則將SQL注入識別特征復制進fingerprint變量并返回。
轉(zhuǎn)換 搜索關鍵字: sql_keywords,在文件libinjection_sqli_data.h中~!
在libinjection中,將SQL關鍵字轉(zhuǎn)換為單個字母時使用的字符集通常是a-z或A-Z。這意味著只有26個不同的字母可以用來表示所有的SQL關鍵字。
為了解決這個問題**,libinjection使用了一些技巧來擴展字母表的大小。其中一個技巧是引入數(shù)字后綴。例如,對于兩個關鍵字SELECT和SET,它們都會被轉(zhuǎn)換為字母s。為了避免沖突,第二個關鍵字SET會被轉(zhuǎn)換為字母s2。**
另一個技巧是使用大寫字母表示特殊的關鍵字。例如,LIMIT和OFFSET是MySQL和PostgreSQL中常用的關鍵字,它們被分別映射為L和O。這樣做的好處是,即使一個關鍵字被映射為小寫字母,仍然可以通過使用大寫字母來表示其他特殊關鍵字,以避免沖突。
需要注意的是,雖然僅有26個字母可以用來表示所有的SQL關鍵字,但由于上面提到的技巧,libinjection能夠支持更多的關鍵字,并確保每個關鍵字都使用唯一的單個字母來表示。
參考文獻
【技術(shù)分享】如何繞過WAF/NGWAF的libinjection實現(xiàn)SQL注入
參考URL: http://www.52bug.cn/hkjs/3025.html
SQL注入與libinjection分析(1)SQL注入
參考URL: https://blog.csdn.net/lqy971966/article/details/105269658
到此這篇關于SQL注入語義分析庫libinjection的文章就介紹到這了,更多相關SQL注入語義分析庫內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
關鍵詞:
2023-03-29 05:57:06
2023-03-29 05:56:38
2023-03-29 05:50:40
2023-03-29 05:47:27
2023-03-29 05:44:06
2023-03-29 05:37:03
2023-03-29 00:53:19
2023-03-28 22:43:18
2023-03-28 21:51:35
2023-03-28 21:39:20
2023-03-28 21:09:38
2023-03-28 20:46:06
2023-03-28 20:42:40
2023-03-28 19:56:20
2023-03-28 19:50:34
2023-03-28 19:46:08
2023-03-28 19:45:13
2023-03-28 19:43:07
2023-03-28 19:42:13
2023-03-28 19:39:56
2023-03-28 19:36:16
2023-03-28 19:36:05
2023-03-28 19:34:17
2023-03-28 18:56:48
2023-03-28 18:19:35
2023-03-28 17:50:16
2023-03-28 17:48:18
2023-03-28 17:43:24
2023-03-28 17:37:00
2023-03-28 17:36:44
2023-03-28 17:36:09
2023-03-28 17:34:49
2023-03-28 17:34:21
2023-03-28 17:32:59
2023-03-28 17:32:41
2023-03-28 17:32:20
2023-03-28 17:31:43
2023-03-28 17:28:40
2023-03-28 17:26:52
2023-03-28 17:23:01
2023-03-28 17:22:12
2023-03-28 17:22:02
2023-03-28 17:21:29
2023-03-28 17:20:04
2023-03-28 17:19:43
2023-03-28 17:18:44
2023-03-28 17:17:58
2023-03-28 17:17:15
2023-03-28 17:17:05
2023-03-28 17:16:40
2023-03-28 17:13:01
2023-03-28 17:03:35
2023-03-28 16:48:39
2023-03-28 16:48:23
2023-03-28 16:45:05
2023-03-28 16:41:09
2023-03-28 16:40:34
2023-03-28 16:38:03
2023-03-28 16:37:20
2023-03-28 16:37:16
2023-03-28 16:36:38
2023-03-28 16:35:22
2023-03-28 16:34:36
2023-03-28 16:34:03
2023-03-28 16:31:32
2023-03-28 16:27:32
2023-03-28 16:27:20
2023-03-28 16:26:58
2023-03-28 16:23:58
2023-03-28 16:23:58
2023-03-28 16:23:30
2023-03-28 16:20:37
2023-03-28 16:20:26
2023-03-28 16:20:25
2023-03-28 16:19:37
2023-03-28 16:19:34
2023-03-28 16:19:17
2023-03-28 16:17:54
2023-03-28 16:16:44
2023-03-28 16:16:44
2023-03-28 16:15:32
2023-03-28 16:15:16
2023-03-28 16:14:30
2023-03-28 16:13:51
2023-03-28 16:12:00
2023-03-28 16:11:23
2023-03-28 16:10:00
2023-03-28 16:08:04
2023-03-28 15:53:42
2023-03-28 15:49:08
2023-03-28 15:45:49
2023-03-28 15:44:28
2023-03-28 15:43:24
2023-03-28 15:43:17
2023-03-28 15:39:24
2023-03-28 15:14:00
2023-03-28 14:02:03
相關新聞