聲明變量在存儲過程和MySQL注射

我有這種情況，例如：聲明變量在存儲過程和MySQL注射

id  value 
1  data_1 
2  20 
3  data_3 
4  15 
5  data_4 
6  data_6

及以下存儲過程：

DELIMITER $$ 

CREATE PROCEDURE `test_2`.`test_procedure` (val int(9)) 
BEGIN 

select * from `test` where `value` = val; 

END

如果我叫這樣的

call test_procedure(20);

程序

我有以下結果：

id  value 
2  20

一切都很好，直到現在。

但我無法理解的是，當我把這樣的過程：

call test_procedure("abc");

我有以下結果：

id  value 
1  data_1 
3  data_3 
5  data_4 
6  data_6

這是MySQL數據庫的正常行爲？

如果我聲明變量「val」爲整數，這不會阻止MySQL注入嗎？

我希望有一個警告或告訴我，輸入值不是一個整數和過程停止，而不是泄露表中不是數字的所有值。

來源

2013-04-26 Catalin

至於奇怪的結果，也可能是由於MySQL的鑄造val參數和value列整數

SELECT CAST("abc" AS SIGNED); -- returns 0 
SELECT CAST("data_1" AS SIGNED); -- also returns 0

所以，如果你把「ABC」和「_1」作爲MySQL的整數，他們是平等的。只是一個理論，但它似乎適合。

如果test.value的零恰好是無效值，那麼如果val爲零，則可以在您的過程中拋出異常。如果沒有，你需要一些其他的解決方法。

順便說一句，我同意tadman在這裏沒有注射威脅。

來源

2013-04-26 17:48:31

這種情況幾乎與下面的語法不相同：「'abc'或1 = 1」，其中此語法總是計算爲true，結果將是表中的所有數據？在我的情況下，結果將是表格中除了數字之外的所有數據，並將信息提供給不必看到它們的人員。也許這不是注射，但在我看來是一個嚴重的安全問題。 – Catalin 2013-04-26 18:15:23

你是對的 - 它與注射相似，因爲它給用戶的應用比他們應該看到的要多。我有一個解決方案的想法;我會盡快將它添加到我的答案中。 – 2013-04-26 18:30:03

Tadman是對的。這個查詢（我測試它）給出了相同的結果：「select * from'test' where value' = 0;」我認爲解決方案將檢查變量「val」是否不同於0，如果是繼續sql查詢，否則停止。 – Catalin 2013-04-26 18:42:10

SQL injection bugs通常是通過允許任意用戶數據插入查詢字符串來實現的。在這種情況下，val引用一個值，而不是任意字符串。如果您使用CONCAT撰寫查詢，則可能會遇到嚴重的麻煩。在這種情況下，你看起來沒問題。

正如你所寫的那樣，即使val在某種程度上，'; DROP DATABASE db; --那麼它將在字符串的基礎上進行比較，而不是作爲一個實際的內聯字符串。這不會比在一個專欄中做這種事情並對它進行比較更糟糕。

您所看到的可能是內部將任意字符串轉換爲0，因此您的與其他值爲0的任何其他值匹配。

來源

2013-04-26 17:37:34 tadman

確實如此。它評估爲0.我不明白爲什麼where子句「where value = 0」給出所有不是數字的記錄。它不應該返回任何結果？ – Catalin 2013-04-26 19:19:00

因爲字母字符被轉換爲0，所以它可能最終成爲'WHERE CONVERT（value，SIGNED）= CONVERT（val，SIGNED）'這是'WHERE 0 = 0' 。 – tadman 2013-04-26 19:22:39

聲明變量在存儲過程和MySQL注射

回答

相關問題