保存SQLQueryStructure(也稱作SQL注入)失敗”在CWE/SANS2月16號出版的排名前25位最危險編程錯誤清單上位列第二。原因是：SQL注入式攻擊對企業用戶構成了巨大的潛在威脅。這是因為一旦SQL注入式攻擊成功，就會導致黑客侵入你的網絡，訪問和毀壞數據并控制計算機。

　　SQL注入是什么？

　　SQL注入式攻擊的原理非常簡單。當一款應用軟件進行用戶數據輸出時，就為惡意用戶入侵制造了機會，從而導致輸入是作為SQL序列出現而不是數據。

　　舉例來說，想象這樣一行代碼：

　　SELECT*FROMUsersWHEREUsername=’$username’ANDPassword=’$password

　　設計這行代碼是要顯示”用戶”框中用戶名和密碼的記錄。使用網絡界面的話，在提示輸入用戶名和密碼的時候，惡意用戶可能會鍵入：

　　1′or’1′=’1

　　1′or’1′=’1

　　然后產生這些的序列：

　　SELECT*FROMUsersWHEREUsername=’1′OR’1′=’1′ANDPassword=’1′OR’1′=’1′

　　這樣黑客就將整個OR條件成功的注入了驗證流程。更糟糕的是，條件’1′=’1′總是正確的，因此這種SQL序列通常會導致黑客規避了驗證流程。

　　使用諸如”；”的字符會在現有序列的末尾另外產生一行序列，作為現有序列注釋的一部分，黑客可能會刪除整個表格或者更改包含的數據。黑客甚至能掌控基礎的操作系統環境，從而控制整個計算機，將計算機淪為供其驅使的肉雞來攻擊網絡中的其他計算機。概括來說SLQ注入式攻擊的結果包括：機密數據泄露，數據完整性的損失，數據丟失，危及整個網絡。

　　如何防御SQL注入式攻擊？

　　最重要的措施就是數據清理和驗證。數據清理通常會涉及任何通過某項功能運行的提交數據(比如MySQL的mysql_real_escape_string()功能)來保證任何存在風險的字符(比如”‘”)不會傳遞到數據的SQL序列。

　　驗證有略微的不同。數據驗證是要確保提交的數據以希望的格式出現。在最基本的層面上，這包括確保電子郵件地址包含”@”標識，提交的數據長度不能超出規定的最大長度。驗證經常會以兩種形式出現：通過風險黑名單或多余的字符和通過在指定情況下才能使用的字符的白名單，這更多會涉及編程人員的工作。雖然驗證通常是在用戶方面發生的行為，但黑客可能會修改或繞過驗證，因此對服務器上的數據加以驗證也很重要。

　　但是數據清理和驗證還遠遠不夠。以下是幫助用戶阻止或緩解SQL注入式攻擊的十種方法：

　　1.不要相信任何人：假設所提交的用戶數據都是存在問題的，對所有數據加以驗證和清潔。

　　2.不要使用可能被規避的動態SQL：無論何時都盡可能采用備好的報表，參數化的查詢或者存儲的流程。