已經14歲的SQL隱碼攻擊仍然是最危險的漏洞

　　自從電腦問世以來，一直有一些人試圖破解電腦。1965年，麻省理工的William D. Mathews發現了在IBM7094平臺上多路資訊計算系統(Multics)相容分時系統(CTSS)密碼檔案的一個缺陷；大約在1971年，John T.Draper 發現了一個穀物玩具口哨可以提供免費電話呼叫；當計算機存在的時候，Chaos計算機俱樂部，cDc社群,2600，臭名昭著的Kevin Mitnick，甚至計算機教父艾倫 圖靈和他在二戰德國英格瑪密碼剋星炸彈，都參與了計算機破解。

　　從1980到1990，世界開始見證了個人電腦，網際網路和全球資訊網的問世。無數家庭中的電話線通過撥號連線發出刺耳的聲音。AOL,CompuServe,Juno開始為家庭使用者提供資訊協議和接入網路的閘道器。資訊時代和資訊保安時代到來了

　　每天有無數的人更新組織網站，其背後的技術也如此。網站有靜態的文字和影像過渡到動態迎合定製內容的網站程式。在瀏覽器中，HTML,CSS和JS變得更強大的組織內容系統。瀏覽器自身也在演變，從IE到Netscape,從Firefox到Chrome，等等。PHP和Perl CGI同其他語言一樣，成為了網站終端實時生成HTML和其他瀏覽器渲染的元素的指令碼的一種選擇。資料庫系統變化無常，MySQL成了最流行的系統。實際上，很多的事物變化無常--.com氣泡？但是一件事仍然重要:web程式安全。

　安全守護者 - OWASP等

　　2001年12月成立了開放Web應用安全專案,作為一個網際網路非盈利組織並針對網路安全討論和進步。  實際上，OWASP儘可能地追蹤每種型別的黑客。社交工程，薄弱的認證系統，跨站指令碼，SQL隱碼攻擊，一般的軟體漏洞等等，OWASP保持追蹤並鼓勵網路社群儘可能地保護網路安全。隨著網際網路的發展，並通過OWASP和它的參與者的努力，有名的黑客也不例外，事情發生了變化。然而，在所有型別的安全攻擊中，注入幾乎是唯一地保持在前十的攻擊方式（通常是特定的資料庫SQL隱碼攻擊）

　　OWASP把注入定義為“不可信的資料被髮送到直譯器作為命令或查詢的一部分”。通常，這種方式允許攻擊者未授權地訪問web應用中資料庫的資料，或者允許他們插入或者選擇一條已經存在的資料。之所以這樣是因為web應用使用使用者的輸入直接插入記錄到資料庫查詢而沒有任何型別的處理。

　　緊接著，可能有人會想，為什麼任何人允許未處理的資料流入資料庫查詢？事實上，如果我們有這個問題的答案，我們可能會得到美國國防部的億萬的美元。

　插曲:什麼是SQL隱碼攻擊？

　　在進一步討論之前我們想暫停一下，確保你，我們珍貴的讀者能夠理解什麼是SQL隱碼攻擊和其後的技術層面。為了簡潔和集中注意力，我們假設從這裡你理解了SQL隱碼攻擊，和它是如何工作以及基本的預防方法。

　　如果你不能做到，請首先參看文章SQL隱碼攻擊你需要知道的事 並留心後續的文章，而我們則繼續深入這個不變的安全問題。理解SQL隱碼攻擊背後的技術有助於突出簡單的事物，和這個重複的安全漏洞的荒謬。

　回放:SQL隱碼攻擊的歷史教訓

　　只要有關聯式資料庫存在，就有SQL隱碼攻擊的媒介。自1999年起，就有了常見漏洞曝光 詞典來追蹤並警告使用者和開發者類似的軟體漏洞。2003年之後，SQL隱碼攻擊仍然在CVE列表中排前10.在2003年到2011年，有3260種漏洞。

　　2012年，Barclaycard的一個代表聲稱97%的資料洩露都是由SQL隱碼攻擊引起的。2011年年尾和2012年年首，在不到一個月的時間裡，超過百萬的網頁遭受到LilupophilupopSQL隱碼攻擊.2008年見證了由於SQL隱碼攻擊引起的經濟失調。甚至在2010年秋季，聯合國官方網站也遭受SQL隱碼攻擊。

　　所有這些統計資料(當然排除了CVE統計)都是過去三年以內的。僅僅三年時間。這也難怪在2011年美國國土安全域性，Mitre和SANA研究所都把SQL隱碼攻擊作為第一危險的安全漏洞。所以，14年之後，它仍然是首要的貌似難以修復的漏洞。

　易下手的漏洞 : 在疏忽中學習或執著

　　在倫敦大學金匠學院的近期研究中，科研人員得出了一個結論：我們的大腦不易改變所以我們人類往往不會輕易地在我們的錯誤中進步。開發者看到並全面認識到軟體開發中的一些錯誤，但是他們內心裡卻不能戰勝並避免犯下過去這些反覆的失誤，這或許是件簡單的事。或者他們見樹不見林，即他們完全理解技術細節卻沒有看到知識應用的巨集圖。

　　至於易下手的漏洞，SQL隱碼攻擊讓它們變成了一個禮物，它保證攻擊者具有易獲得非法訪問網站或者其他SQL後臺系統。這個結論是基於成功的概率得到的，如果14年的歷史資料可信的。從根本上來講，這主要是由於大多數顯而易見的問題：我們仍然使用關係SQL資料庫。

　　如果我們使用NoSQL資料庫系統比如MongoDB或者CouchDB,那麼這些攻擊就不會發生了，或者至少不會像SQL隱碼攻擊那樣簡單了。但那不是真正的原因，甚至也不是一個合理可行的解決方案。真正的原因在於軟體和web應用開發者們真的像倫敦大學得出的結論一樣，一旦人類把事情搞砸了，他們就不能輕易地學習和適應。

　低代價，高回報；利用一個易得手的漏洞

　　通過比較，一次分不是拒絕服務攻擊(DDOS)需要協調和利用數百到數萬的被感染的系統來實施這樣的攻擊。而SQL隱碼攻擊在一臺電腦上就可以完成，只需要你有點耐心，不斷嘗試，不怕失敗，加上一些創造力和運氣。完成SQL隱碼攻擊真的不需要掌握太多的技巧。實際上，一個指令碼小子在完全不懂任何SQL隱碼攻擊的情況下都可以完成。通過使用任何一款免費工具，實施攻擊就是那麼簡單。

　　或許有的SQL隱碼攻擊是由偷工減料的開發或者漏洞引起的，但是實際上，經常有3大經常反覆發生的錯誤導致SQL隱碼攻擊的出現。它們包過以下：

　　忽視最小特權原則

　　這個原則相當簡單，也頻繁地被忽視，它僅宣告瞭一個使用者，程式或者其他實體完成其任務的最小需要許可權。舉個例子，一個日誌資料表不需要DELETE和UPDATE許可權，而資料庫管理員通常授予一個服務所有可能的許可權而不是剛好適合所需服務的許可權。

　　敏感資料聚集

　　沒有理由把信用卡資料和文章資料放在同一資料庫中。也沒有理由明文儲存密碼或者使用糟糕的雜湊技術。如果你把你的資料分段，並分散開，那麼你的資料庫和其內容就不是有價值的目標。就像，你會把你所有的財產放在家裡嗎？還是把它們放到保險箱中。

　　盲目信任未處理的使用者輸入

　　這是為什麼SQL隱碼攻擊會發生。當使用者輸入未加處理時，攻擊者就有能力完成SQL隱碼攻擊，上面的兩點也闡述過。一旦使用者通過未加處理的輸入獲得訪問許可權，敏感資料的可用性和沒有限制的特權給了他們一切想要肆虐。

　　就是這樣的。僅僅上述的三個問題就已經導致了數以百萬的網頁在短短一個月內遭受攻擊，包括聯合國官網和一些知名網站。這些問題一直保持在OWASP的前十列表中。這些問題往往很荒唐，它是如此簡單的三個問題啊，盡然不斷導致SQL隱碼攻擊。我們開發者該如何做呢？

　　在之後的一系列SQL隱碼攻擊的文章中，我們將繼續闡述SQL隱碼攻擊的技術細節以及如何預防。而現在，最強調的重要的一點就是開發者和系統管理員不要掉入前面提到的三個問題。開發者需要保證，他們為一個web應用實現所需的最小許可權，隔離或加密資料來減弱資料庫的攻擊價值，最重要的是，要經常處理使用者輸入。這些在技術上再也簡單不過了，如果能像SQL隱碼攻擊一貫地排在前十那樣一貫地應用這些原則，就能消除前10名單裡的SQL隱碼攻擊。

　自動監測Web應用在SQL隱碼攻擊方面的脆弱性

　　監測站點和Web應用是否在SQL隱碼攻擊方面很脆弱的簡單並且快速的方法是使用諸如NetSparker這樣的自動web應用安全掃描器對它們進行掃描。

　　Netsparker是一個很容易誤報的自由的web應用安全掃描器，它可用來識別web應用或者web站點中諸如SQL隱碼攻擊和跨站指令碼攻擊等方面的脆弱性。可以下載Netsparker試用版測試站點的脆弱性，或者通過Netsparker產品描述頁面瞭解更多這方面的資訊。

　　英文來源：sql-injection-vulnerability-history