2012-03-15 56 views

回答

1

不要直接將GET變量傳遞給您的查詢。如果你沒有,那麼我可以做的SQL注入這樣的:

http://www.mytestapp.com/results?limit=1%3BDROP%20TABLE%20USERS 

和您的查詢最終會看起來像:

select * from some_table where parameter = 3 limit 1;DROP TABLE USERS 

我假設你正在試圖做的分頁。如果是的話,你會希望有類似:

http://www.mytestapp.com/results?page=1&size=10 

然後,在你的後臺,驗證pagesize均爲整數,並同時具有合理的規模。例如,可能對size可能設置了限制,例如可能只有10到100的倍數。

+0

我同意這個問題。對大小設置限制被視爲應用[白名單](http://en.wikipedia.org/wiki/Whitelist),這是一個很好的安全措施。讓用戶告訴你他們想要的是好的,但只允許他們做他們被允許做的事,而不管他們要求什麼。 – 2012-03-15 17:15:07

+0

我仍在驗證get參數。它需要是整數,所以?limit = 1%3BDROP%20TABLE%20USERS將無法工作,因爲「1; DROP TABLE USERS」不是數字。 – 2012-03-15 17:31:11

+0

不過,如果用戶提供了實例「18446744073709551615」作爲極限參數,那麼該網站會發生什麼情況? 在一個龐大的數據庫上,select查詢會佔用所有MySQL資源並凍結整個站點? – 2012-03-15 17:33:19

0

在獲取字符串中傳遞參數的主要問題是它可以打開你的SQL注入攻擊。如果有人通過這個:

http://www.mytestapp.com/results?limit=1234;drop表用戶;

您需要仔細觀察以確保清理輸入。

假設您已經對此有所瞭解並瞭解安全性,那麼另一個問題是它將您的限制交付給最終用戶。他們可以通過使用非常大的數字來有效地消除限制。根據查詢的複雜程度和表的大小,這可能會對服務器性能和其他用戶產生負面影響。

由於限制條款中的大量數據,我不知道有任何其他問題。例如,我認爲您不需要擔心溢出問題。

+0

我明白了。謝謝! – 2012-03-15 17:38:15

+0

不要忘記接受答案。 ;) – Ilion 2012-03-15 17:48:41

0

與其他人一樣,在將輸入傳遞到數據庫之前驗證輸入,確保它是整數,不包含除數字之外的任何內容,並且具有合理的大小值。對於這種情況,您將有效防止SQL注入。

你也不應該通過連接你的命令邏輯和來自不受信任的源的參數來建立查詢字符串。您應該使用參數化查詢,您可以在其中確定數據在創建時適合SQL語句的位置,然後在稍後綁定該值。這有一個作用,允許數據庫區分你打算作爲數據的意圖,防止SQL注入,即使你在輸入驗證中錯過了一個攻擊案例(對於這種特殊情況,白名單很容易......)這並非總是如此,甚至是不可能的)。您可以在精心編寫的OWASP SQL Injection Prevention Cheat Sheet頁面上閱讀關於參數化查詢的更多信息。