楊浩

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

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

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

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

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

Users

Inventory

Products

Sales

等…

這都是一些使用率非常高的表名，特別是一些數(shù)據(jù)庫開發(fā)人員為了節(jié)約時間，使用默認表名的情況。這些都是非常危險的操作，應從初始的開發(fā)上對這些細節(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/其他人該解決的問題

確實SQL注入是開發(fā)人員/dba/其他人該解決的問題。但這絕對不是單方面人員的問題，安全是需要多層面的配合的，無論是開發(fā)人員/dba/其他人都需要解決問題。

防止sql注入很困難。

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

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

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

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

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