SQL注入漏洞的奇數格式？

我一直在努力學習更多關於SQL注入攻擊的知識。我理解這個原則，但是當我看到其中的一些攻擊時，我不知道他們是如何在做他們正在做的事情。SQL注入漏洞的奇數格式？

經常會有不均勻的引號，並且通過十六進制字符混淆很多。

我沒有得到十六進制字符......當然，它們被瀏覽器翻譯回ASCII，所以有什麼意義呢？

但是，我主要被奇怪的引用困惑。我現在很難找到一個例子，但是通常似乎引用會在聲明結束之前的某個時刻結束，當時我會認爲它會在最後？

也許一個例子是「1或1 = 1

什麼這樣的說法做共同使用？

來源

2010-11-23 Josh

好問題。它很難過，看到我是唯一一個在SQL注入攻擊中實際使用過這種技術的人。 – rook 2010-11-23 23:39:49

我沒有得到個十六進制字符...，他們肯定是由瀏覽器

都能跟得上翻譯回 ASCII。

但是，我主要被奇怪的引用困惑。我有問題現在找到一個例子，但是它通常似乎是在結束之前的某個點結束的聲明，當我想認爲它會在最後？

想象一下，您正在構建內聯SQL，而不是像您應該那樣使用參數替換。我們將使用一種看起來很像PHP的虛構語言，因爲沒有特別的原因。

$sql = "delete from foo where bar = '" + $param + "'";

所以，現在，想象$param得到由瀏覽器設置等...

$param = "' or 1=1 --"

（我們假裝喜歡--是這裏的SQL註釋序列。如果不是有辦法在那附近）

所以，現在，你的SQL在字符串替換完成後是什麼？

delete from foo where bar = '' or 1=1 --'

將刪除foo中的每條記錄。

這一直是有目的的簡單，但它應該給你一個很好的想法，不平衡的報價是什麼。

來源

2010-11-23 22:31:20 Donnie

@Rook - 大部分答案與十六進制編碼無關。我剛剛糾正了他對瀏覽器的假設，並繼續前進。另外，我沒有看到他的問題是如何針對mysql的，所以你關於mysql_query的爭論也是相當虛假的。 – Donnie 2010-11-24 00:21:47

這並不回答這個問題，你應該閱讀我發佈的一個sql注入攻擊。 – rook 2010-11-24 00:44:24

假設我們有一個表單，我們提交一個名稱字段的表單。名稱用於變量$ Name。然後運行該查詢：

INSERT INTO Students VALUES ('$Name')

它將被翻譯成：

INSERT INTO Students VALUES ('Robert'); DROP TABLE STUDENTS; --')

的 - 是一個註釋分隔符。之後，一切都將被忽略。 '用於分隔字符串文字。

在攻擊中使用十六進制字符有一些原因。其中一個是混淆，另一個是繞過一些天真的安全措施。

來源

2010-11-23 22:33:54

現在，分組查詢現在不被最普遍的sql服務器支持。另外 - 不是唯一的註釋分隔符，例如MySQL有/ * ...使用十六進制編碼很難進行混淆，因爲您無法隱藏實際查詢，只能查看其中的值。它主要用於因爲沒有必要使用單引號來表示加數值，所以當你注入複雜時，你不必擔心引號的數量，並且可以計算注入查詢的整個邏輯。 – 2010-11-23 22:40:39

這是SQL注入的SQL Server示例。這將永遠不會與`mysq_query（）`一起工作，並且它不會處理十六進制編碼。 – rook 2010-11-23 23:23:32

至於引用不齊;發生sql注入其中，編碼器沒有過濾用戶輸入的危險字符，如單引號 - 考慮下面的語句

SELECT * FROM admin WHERE username='$_GET["user"]' and password='$_GET["pass"]'

，如果我知道，有效的用戶名爲admin，並插入'or 1=1我會得到以下

SELECT * FROM admin WHERE username='admin' and password='something' or 1=1

這將導致查詢總是返回true，因爲無論密碼的值如何，表達式的左側都將始終爲true。

這是sql注入的最簡單的例子，你會發現攻擊者根本不需要使用引號，或者可以使用註釋分隔符（例如--或/*）將其餘的查詢註釋掉，如果在注入點之後有更多參數通過。

至於十六進制編碼，可能有幾個原因，避免過濾，使用十六進制編碼值更簡單，因爲您不必擔心引用查詢中的所有值。例如，這是有用的，如果你想使用concat共同譜寫兩場在一起，就像這樣：

inject.php?id=1 and 1=0 union select 1,2,concat(username,0x3a3a,password) from admin

這將提供第三排是可見的一個，換來isntance admin::admin。如果我沒有使用十六進制編碼，我會做到這一點：

inject.php?id=1 and 1=0 union select 1,2,concat(username,'::',password) from admin

這可能是與上述addslashes功能的問題，也有寫得不好的正則表達式的消毒功能，或者如果你有非常複雜的查詢。

Sql注入是非常廣泛的話題，我已經涵蓋甚至幾乎沒有通過介紹。

來源

2010-11-23 22:35:59

有些情況下，sql注入禁止引用標記。在這種情況下，攻擊者必須使用編碼方法，例如對他的字符串進行十六進制編碼。例如'/etc/passwd'可以寫成0x2f6574632f706173737764，它不需要引號。以下是禁止引用標記的易受攻擊查詢的示例。：

mysql_query("select name from users where id=".addslashes($_GET[id]));

如果你想使用MySQL之類的函數load_file()，那麼你必須要使用十六進制編碼。

的PoC：/vuln.php?id=1 union select load_file(0x2f6574632f706173737764)

在這種情況下，/ etc/passwd文件被讀出，也將是第二排。

下面是我在我的MySQL SQL注入的攻擊使用十六進制編碼功能的變化：

function charEncode($string){ 
    $char="char("; 
    $size=strlen($string); 
    for($x=0;$x<$size;$x++){ 
     $char.=ord($string[$x]).","; 
    } 
    $char[strlen($char)-1]=")%00"; 
    return $char; 
}

我用這個確切的方法exploiting HLStats 1.35。我還在我的php nuke exploit中使用了此功能，以繞過使用into outfile將<?php?>寫入磁盤的xss過濾器。其中重要的是要注意，into outfile是一個查詢運算符，它不接受輸出到函數或十六進制編碼的字符串，它只接受帶引號的字符串作爲路徑，因此在易受攻擊的查詢上面into outfile不能被攻擊者使用。 load_file()是一個函數調用，可以使用十六進制編碼。

來源

2010-11-23 23:19:49 rook

SQL注入漏洞的奇數格式？

回答

相關問題