SQL注入已是一個老生常談的話題，但時至今日仍是我們作為開發(fā)人員和數(shù)據(jù)庫專業(yè)人員所面臨的最大安全風(fēng)險之一。
每年都有數(shù)以百萬計的個人用戶信息被泄露，這大部分都是由于代碼編寫過程中SQL查詢語句不嚴(yán)謹(jǐn)造成的。其實(shí)只要正確的編寫，SQL注入是完全可以預(yù)防的。
本文我將著重說明人們對SQL注入常見的四個誤解。安全無小事，任何人都不應(yīng)對此抱有任何的幻想！
1.”我的數(shù)據(jù)庫信息并未公開，因此這是安全的“
可能你對數(shù)據(jù)庫信息的保密工作做的很到位，但這樣真的就安全了嗎？攻擊者其實(shí)只需具備對常見數(shù)據(jù)庫庫名表名的了解，就完全有可能猜出它們。例如在你的數(shù)據(jù)庫中可能創(chuàng)建了以下的表：
Users
Inventory
Products
Sales
等…
這都是一些使用率非常高的表名，特別是一些數(shù)據(jù)庫開發(fā)人員為了節(jié)約時間，使用默認(rèn)表名的情況。這些都是非常危險的操作，應(yīng)從初始的開發(fā)上對這些細(xì)節(jié)重視起來。
2.”創(chuàng)建混淆性的表名列名，命名約定只有自己能理解“
這樣做看似攻擊者就無法輕易的猜解出名稱了，但你千萬不要忽視了像sys.objects和sys.columns這樣的系統(tǒng)表的存在！
SELECT
t.name, c.name
FROM
sys.objects t
INNER JOIN sys.columns c on t.object_id = c.object_id
on t.object_id = c.object_id
攻擊者可以輕松地編寫以上查詢，從而獲知你的“安全”命名約定。
如果你有不常用的表名，那很好，但千萬不要將它作為你唯一的防御手段。
3.“注入是開發(fā)者/dba/其他人該解決的問題”
確實(shí)SQL注入是開發(fā)人員/dba/其他人該解決的問題。但這絕對不是單方面人員的問題，安全是需要多層面的配合的，無論是開發(fā)人員/dba/其他人都需要解決問題。
防止sql注入很困難。
開發(fā)者應(yīng)該驗證，過濾，參數(shù)化……DBA應(yīng)該參數(shù)化，過濾，限制訪問等。
應(yīng)用程序和數(shù)據(jù)庫中的多層安全性是有效防止SQL注入攻擊的唯一方法。
4.“網(wǎng)絡(luò)上的目標(biāo)眾多，被攻擊的對象絕對不會是我”
或許你覺得你不會那么倒霉，或者你的業(yè)務(wù)數(shù)據(jù)不值得攻擊者竊取。但你別忘了大多數(shù)的SQL注入攻擊，都可以使用像sqlmap這樣的完全自動化的工具。他們或許對你的業(yè)務(wù)并不關(guān)心，但這并不妨礙他們通過自動化的方式竊取你的用戶數(shù)據(jù)。
