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