使用非SQL數據庫是否避免防範「SQL注入」？

這可能看起來像一個明顯的（或不是那麼明顯）的問題，但讓我解釋一下。我正在使用Google的數據庫技術BigTable編寫Google App Engine網站。任何App Engine編碼器都會知道Google有自己的有限查詢語言，稱爲GQL。因此，我不想在我的應用程序中對SQL（或GQL）注入進行任何檢查，因爲我認爲Google沒有在其後端方法上使用原始字符串查詢來獲取數據。此外，像CouchDB，MongoDB和其他對象或文檔（又名NoSQL）數據庫的數據庫技術庫似乎無需檢查惡意用戶是否正在注入數據庫操作命令。他們經常有圖書館直接映射數據庫中的對象，以您選擇的語言來對象。我知道有很多SQL庫可以做到這一點，但我認爲在某種程度上他們將參數組合起來以對字符串運行查詢，因此即使對於這些框架，我也必須使用SQL注入保護。使用非SQL數據庫是否避免防範「SQL注入」？

我是否近視？或者，直到下一個偉大的數據庫系統成功，這只是一個時間問題，然後我會看到注入這些系統？

來源

2009-12-01 daveslab

「注入」漏洞與文本上下文不匹配有關。每次將文本字符串放入另一個字符串上下文中時，都需要進行編碼以適應已更改的上下文。盲目地將字符串混淆在一起似乎誘人簡單，但字符串處理的困難是欺騙性的。

純粹基於對象的接口的數據庫不受注入漏洞的影響，就像參數化查詢在SQL中一樣。攻擊者沒有任何東西可以放在他的字符串中，以打破你放置他的字符串字面上下文。

但是GQL並不是其中之一。這是一種字符串查詢語言，如果您將不可信的非轉義材料連接到像"WHERE title='%s'" % title這樣的查詢中，則您與使用全功能SQL時一樣脆弱。也許GQL的有限功能使其更難以利用它來徹底破壞應用程序，但一般來說並非不可能，並且在最好的情況下，您的應用程序仍然是錯誤的，並且在人們試圖合法使用撇號時會崩潰。

GQL有一個參數綁定接口。用它。抵制字符串黑客的魅力。

來源

2009-12-01 02:11:43 bobince

糾正我，如果我錯了，但GQL只允許SELECT查詢，所以假設你從'SELECT ... FROM kind'開始，沒有什麼可以附加到修改數據，除了選擇相同實體類型的「行」以外，沒有其他辦法可以做，除非選擇「行」，或許你不打算看到這些行。如果用戶被允許查看特定類型的所有「行」，則不存在注入攻擊。 – Eloff

當然，但是SELECT可能會在錯誤的手中足夠危險，典型的例子是'WHERE username ='...'AND password ='...''被擴展爲WHERE username ='admin'或者username =' x'和密碼='x'可以登錄到沒有密碼的管理員帳戶，但取決於在應用程序邏輯上有很多潛在的漏洞。 – bobince

像GQL這樣的SQL子集顯然仍然關注它 - 但像CouchDB，Voldemort等純粹的非SQL數據庫應該讓&獲得數據，而不用擔心SQL注入式的攻擊。

然而，這並不是原諒你做內容驗證，因爲雖然它可能不會破壞數據庫，但它可能會破壞你的應用程序並允許像XSS（如果它是一個Web應用程序）的東西。

來源

2009-12-01 01:53:15

無論何時，來自用戶輸入或由用戶輸入操縱的數據都用於控制代碼的執行，需要進行消毒。我見過代碼使用用戶輸入來執行命令而不消毒輸入。它沒有被利用，但如果它已經是一個可怕的攻擊媒介。

來源

2009-12-01 01:58:30

SQl注入只是一種安全漏洞的一個子集，其中任何非受控輸入被評估。

在技術上，你可以「注入」JavaScript等等。

來源

2009-12-01 01:58:38

「JavaScript注入」是「XSS」或「跨站點腳本」。「 – yfeldblum

@Justice，你不需要跨站點來注入JS，你可以在本地輸入一個域名來執行它 –

可以肯定的是，@Justice，我記住了XSS，但沒有故意提到它，因爲這是一個蠕蟲:) – daveslab

使用非SQL數據庫是否避免防範「SQL注入」？

回答

相關問題