SQL注入攻擊（SQL injection）是目前網站安全以及伺服器安全層面上是最具有攻擊性，危害性較高，被黑客利用最多的一個漏洞，基本上針對于網站代碼，包括JAVA JSP PHP ASP apache tomcat 語言開發的代碼都會存在sql注入漏洞。
随着JAVA JSP架構的市場佔有率越來越多，許多平台都使用JAVA開發，本文通過對sql注入的詳細分析，從代碼層面以及伺服器層面，根本上來防止sql注入攻擊。
SQL注入漏洞的原理很簡單，通俗來講：就是程式員在編寫網站代碼的時候，一些執行資料庫指令的代碼，程式員沒有認真寫以及認真過濾，導緻可以将外部的惡意參數拼接到SQL語句當中去，直接傳入到資料庫中去執行，導緻黑客可以執行一些查詢使用者賬戶密碼，修改資訊，執行系統指令的安全操作。
下面我們來搭建一個JAVA環境的網站，設計一個可以查詢使用者資訊的一個api 服務接口，我們采用的都是springboot + jersey 來搭建我們的web服務查詢架構。
資料庫是Mysql 架構的，建立一個新的資料庫表:admin，然後建立管理者賬戶跟密碼(采用md5加密方式），這樣我們的使用者資訊有了，就可以提供查詢了。我們把springboot + jersey架構服務搭建起來，然後寫一下查詢的代碼到架構裡。Sine安全公司是一家專注于：伺服器安全、網站安全、網站安全檢測、網站漏洞修複,滲透測試,安全服務于一體的網絡安全服務提供商。
我們再來測試下查詢的接口，是否可以正常輸出：
通過網站進行get請求送出，Web服務接口傳回200并輸出了使用者名為admin的管理者賬戶以及密碼。這樣的輸出是屬于正常的，但是我們在網站端發送一條帶有逗号的GET請求，會發現報錯了。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''xxxx''' at line 1。 也就是說上面的查詢是錯誤的，因為我們添加了一個逗号在裡面，導緻傳入到資料庫并執行的同時，資料庫傳回的錯誤提示。
SQL注入詳情解析：
GET的網站時候參數的時候，傳入了一個String類型的name參數值，并且通過字元串聯起來，建構了資料庫的查詢語句。在正常操作的情況下，使用者會傳入合法的name參數值進行資料庫查詢，但是攻擊者會編造一些惡意的參數，隻要參數通過字元串拼接後依然是一句合法的SQL查詢，此時SQL注入就發生了。正如我們上文輸入的name=xxxx'or'a'='a與我們接口中的查詢語句進行拼接後構成如下SQL語句如圖：
當接口執行name=xxxx'or'a'='a這個SQL語句後，系統背景也就相當于免費的送給黑客了，黑客一看到管理者密碼這個hash，都不用去cmd5解密了，攻擊者就會直接使用123456這個密碼去登入網站的背景管理系統。為什麼？因為123456的md5哈希太常見了，這就是很多JAVA網站的現實，在網站安全以及弱密碼方面簡直做的不忍直視。
好了，現在我們應該明白了，SQL Injection原因就是由于傳入的參數與系統的SQL拼接成了合法的SQL而導緻的，而其本質還是将使用者輸入的資料當做了代碼執行。在系統中隻要有一個SQL注入點被黑客發現，那麼黑客基本上可以執行任意想執行的SQL語句了，例如添加一個管理者，查詢所有表，修改使用者密碼等等。
以上是對sql注入攻擊的詳情，下文會詳細的介紹，如何去防範sql注入的攻擊，知彼知己才能百戰不殆。了解了sql的攻擊原理，才能更好去防禦sql注入攻擊。
網站安全需要精心雕琢，伺服器安全是100 - 1 = 0的業務，即使你防禦了99%的攻擊，那還不算勝利，隻要有一次網站被入侵了，那就有可能給公司帶來很嚴重的損失跟後果。如果不懂網站防SQL攻擊的的話，也可以找專業的安全公司來部署防sql注入攻擊部署，國内安全公司像綠盟、Sinesafe、在安全方面都是做的比較不錯的。
SQL注入的其他防範辦法
很多公司都會存在老系統中有大量SQL注入風險代碼的問題，但是由于其已穩定支援公司業務很久，不宜采用大面積代碼更新的方式來消除注入隐患，是以需要考慮其采用他方式來防範SQL注入。除了在在SQL執行方式上防範SQL注入，很多時候還可以通過架構上，或者通過其他過濾方式來達到防止SQL注入的效果。
一切輸入都是不安全的：對于接口的調用參數，要進行格式比對，例如admin的通過name查詢的接口，與之比對的Path應該使用正則比對（因為使用者名中不應該存在特殊字元），進而確定傳入參數是程式控制範圍之内的參數，即隻接受已知的良好輸入值，拒絕不良輸入。注意：驗證參數應将它與輸出編碼技術結合使用。
利用分層設計來避免危險：前端盡量靜态化，盡量少的暴露可以通路到DAO層的接口到公網環境中，如果現有項目，很難修改存在注入的代碼，可以考慮在web服務之前增加WAF進行流量過濾，當然代碼上就不給hacker留有攻擊的漏洞才最好的方案。也可以在擁有nginx的架構下，采用OpenRestry做流量過濾，将一些特殊字元進行轉義處理。
盡量使用預編譯SQL語句：由于動态SQL語句是引發SQL注入的根源。應使用預編譯語句來組裝SQL查詢。
規範化：将輸入安裝規定編碼解碼後再進行輸入參數過濾和輸出編碼處理；拒絕一切非規範格式的編碼。