James Jenkins
2017-02-28 22:18:55 UTC
我正在閱讀有關SQL注入的內容，並看到了這一點，這使我開始思考：
輸入字段應盡可能小，以減少黑客將SQL代碼壓入該字段的可能性不會被截斷（通常會導致T-SQL語法錯誤）。
來源： Microsoft SQL Server 2008 R2釋放
SQL注入會造成損害的最短字段大小是多少？
損害是數據庫修改或返回設計所不希望的結果。在兩個字符字段中包含結束註釋標記（-）不會造成危害，只會導致查詢失敗。潛在的黑客可能會知道該領域容易受到注入，但他們無法利用它。
如果給出的錯誤是冗長的，則可能足以獲取有用的信息，尤其是在開發人員將表名視為“秘密”的情況下……
並非總是在輸入字段上執行SQL注入-您可以將URL中的orderby子句作為目標，例如可以執行惡意sql的位置。字段的有限大小不會阻止這一點。
@iain:好點了。另外，限制（我假設）接收到的HTML表單數據的字段長度並不能使我成為避免sql注入的好方法。避免SQL注入基本上是一個可以解決的問題。只需讓數據庫連接庫通過使用帶佔位符的預備語句來處理它，而不是使用編程語言的字符串函數將查詢粘貼到一起，並由於您忘記防止漏洞號59654而把它弄錯了。
@Pascal“ *基本上避免了SQL注入問題； *”僅適用於已應用適當注意事項的新代碼。現有許多代碼尚未解決問題。大概存在一個字符長度，在此長度以下，解決現有問題的壓力要小於長度較長的字符。
我是唯一認為那本書應該被公開焚毀的人嗎？參數化查詢已經存在了很長時間，以至於筆者讓我相信它們根本不知道他們在說什麼。聽起來好像他們從一組博客中復制並粘貼了垃圾，並發行了一本書。他們可能還告訴您，您應該練習用較小的子彈射擊，以便增強對較大子彈的免疫力。
@MonkeyZeus <聳肩/>這不是技術書籍的例外，而是更多的規則。當非安全專家提供安全建議時，通常質量很差。
0個字符怎麼樣？並且僅在服務器上經過驗證的情況下。
-1
@MonkeyZeus我同意這令人不快，但我還是特別喜歡閱讀技術書籍和編程書籍中的安全建議。覆蓋範圍通常是深淵或完全不存在。例如，我有一本書從頭開始構建電子商務系統，簡要討論了HTTPS的使用，然後宣布對安全性的進一步討論不在本書的討論範圍之內。
@Xander我想說“別處看看”比大膽宣稱“在將數據發送到服務器之前，使用JavaScript和服務器生成的隨機密鑰對錶單數據進行模糊處理”更為崇高。至少那本電子商務書說：“嗨，我們不希望您的服務器被沙紙陰莖遮蓋住，因此，如果您關心安全性，那麼請閱讀一本關於它的好書。我們的書只是教您如何構建e商業網站，而不是如何保護它。”
我反對原則上的書籍刻錄-但是會投票給作者帶回存貨-“這通常會導致T-SQL語法錯誤”-SQL Injection的全部重點是使您提交的數據與預定目的地的範圍。
根據其他答案，較短的字段長度不會阻止問題。我最近在一個帶有8個字符的用戶名字段的舊版應用程序上工作（並且在代碼中檢查了8個字符），但是它仍然可以進行SQL注入。當在註入中還使用密碼字段時，情況變得更糟。
儘管我100％同意通常如何解決這些安全問題以及該書中的建議有多糟糕，但我認為該建議很糟糕，主要是因為它很可能使人們愚弄自己以為採取“預防措施”他們保護自己免受SQL注入的侵害，這也是不好的，因為它鼓勵在有可能（且容易）消除風險的情況下追求降低風險。沒有辦法否認該引用並沒有聲稱可以防止SQL注入。它只是聲稱要“降低可能性”（這是愚蠢的並且具有誤導性）。
@MonkeyZeus許多DB API仍然無法支持數組值的參數，例如運算符IN右側的那些。要變通解決此問題，您需要在查詢中包括可變數量的參數，這時最終會“粘貼”一系列佔位符，並使位置佔位符（`？）的順序在語句之間保持同步並且值數組很難逃脫。