楊浩

SQL注入已是一個(gè)老生常談的話題，但時(shí)至今日仍是我們作為開發(fā)人員和數(shù)據(jù)庫專業(yè)人員所面臨的最大安全風(fēng)險(xiǎn)之一。

每年都有數(shù)以百萬計(jì)的個(gè)人用戶信息被泄露，這大部分都是由于代碼編寫過程中SQL查詢語句不嚴(yán)謹(jǐn)造成的。其實(shí)只要正確的編寫，SQL注入是完全可以預(yù)防的。

本文將著重說明人們對(duì)SQL注入常見的四個(gè)誤解。安全無小事，任何人都不應(yīng)對(duì)此抱有任何的幻想！

1.我的數(shù)據(jù)庫信息并未公開，因此這是安全的

可能你對(duì)數(shù)據(jù)庫信息的保密工作做的很到位，但這樣真的就安全了嗎？攻擊者其實(shí)只需具備對(duì)常見數(shù)據(jù)庫庫名表名的了解，就完全有可能猜出它們。例如在你的數(shù)據(jù)庫中可能創(chuàng)建了以下的表：

Users

Inventory

Products

Sales

等…

這都是一些使用率非常高的表名，特別是一些數(shù)據(jù)庫開發(fā)人員為了節(jié)約時(shí)間，使用默認(rèn)表名的情況。這些都是非常危險(xiǎn)的操作，應(yīng)從初始的開發(fā)上對(duì)這些細(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/其他人該解決的問題。但這絕對(duì)不是單方面人員的問題，安全是需要多層面的配合的，無論是開發(fā)人員/dba/其他人都需要解決問題。

防止sql注入很困難。

開發(fā)者應(yīng)該驗(yàn)證，過濾，參數(shù)化……DBA應(yīng)該參數(shù)化，過濾，限制訪問等。

應(yīng)用程序和數(shù)據(jù)庫中的多層安全性是有效防止SQL注入攻擊的唯一方法。

4.網(wǎng)絡(luò)上的目標(biāo)眾多，被攻擊的對(duì)象絕對(duì)不會(huì)是我

或許覺得你不會(huì)那么倒霉，或者你的業(yè)務(wù)數(shù)據(jù)不值得攻擊者竊取。但別忘了大多數(shù)的SQL注入攻擊，都可以使用像sqlmap完全自動(dòng)化的工具。他們或許對(duì)你的業(yè)務(wù)并不關(guān)心，但這并不妨礙他們通過自動(dòng)化的方式竊取你的用戶數(shù)據(jù)。

記住！無論你的業(yè)務(wù)規(guī)模大小，都無法避免來自自動(dòng)化SQL注入工具的威脅。