JAVA網站如何防止sql注入攻擊,是目前許多網站運營者比較頭疼的一個安全問題,
隨著java orm技術的快速崛起,Java web開發的網站,在大數據網站發展上已經越來越遠離SQL
注入攻擊的問題了,在現在互聯網中,使用PHP和Python構建的web應用是目前SQL注入的重災
區。本文雖然是從JAVA的角度來研究SQL注入代碼的問題,但原理上同樣適用於其他開發語言,
希望讀者可以通過此文,融會貫通.
下面介紹一下幾個java常用的框架介紹:MyBatis 是支持定制化 SQL、存儲過程以及高級映
射的優秀的持久層框架, 其幾乎避免了所有的 JDBC 代碼和手動設置參數以及獲取結果集。同
時,MyBatis 可以對配置和原生Map使用簡單的 XML 或註解,將接口和 Java 的 POJOs
(Plain Old Java Objects,普通的 Java對像)映射成數據庫中的記錄,因此mybatis現在在市場中采
用率也非常高。這裡我們定義如下一個mapper,來實現通過用戶名查詢管理員的接口:eSafe白帽資安網
公司是一家專注於:主機安全、網站安全、網站安全檢測、網站漏洞修復,滲透測試,安全服務於
射的優秀的持久層框架, 其幾乎避免了所有的 JDBC 代碼和手動設置參數以及獲取結果集。同
時,MyBatis 可以對配置和原生Map使用簡單的 XML 或註解,將接口和 Java 的 POJOs
(Plain Old Java Objects,普通的 Java對像)映射成數據庫中的記錄,因此mybatis現在在市場中采
用率也非常高。這裡我們定義如下一個mapper,來實現通過用戶名查詢管理員的接口:eSafe白帽資安網
公司是一家專注於:主機安全、網站安全、網站安全檢測、網站漏洞修復,滲透測試,安全服務於
一體的網絡安全服務提供商。
原來在mybatis中如果以${}形式聲明為SQL傳遞參數,mybatis將不會進行參數預處理,會直接動
態拼接SQL語句,此時就會存在被注入的風險,所以在使用mybatis作為持久框架時應盡量避免采
用${}的形式進行參數傳遞,如果無法避免(有些SQL語句如like、in、order by等,程序員可能依
然會選擇${}的方式傳參),那就需要對傳入參數自行進行轉義過濾。
態拼接SQL語句,此時就會存在被注入的風險,所以在使用mybatis作為持久框架時應盡量避免采
用${}的形式進行參數傳遞,如果無法避免(有些SQL語句如like、in、order by等,程序員可能依
然會選擇${}的方式傳參),那就需要對傳入參數自行進行轉義過濾。
很多JAVA開發的網站,使用了比較基礎的JDBC的方式進行數據庫操作,直接使JDBC構
建DAO在比較老的系統中還是很常見的,但這並不意味著使用JDBC就一定不安全,如果我將傳
入的參數 xxxx'or'a'='a 整體作為參數進行name查詢,那就不會產生SQL注入。在JDBC中,提
供了PreparedStatement (預處理執行語句)的方式,可以對SQL語句進行查詢參數化,使用預
處理後的代碼如下:
建DAO在比較老的系統中還是很常見的,但這並不意味著使用JDBC就一定不安全,如果我將傳
入的參數 xxxx'or'a'='a 整體作為參數進行name查詢,那就不會產生SQL注入。在JDBC中,提
供了PreparedStatement (預處理執行語句)的方式,可以對SQL語句進行查詢參數化,使用預
處理後的代碼如下:
同樣,我們使用上文的注入方式注入 ,此時我們發現,SQL注入並沒有成功。現在我們來打印一
下被被預處理後的SQL,看看有什麼變化。看到了嗎?所有的 ' 都被 \' 轉義掉了,從而可以確保
SQL的查詢參數就是參數,不會被惡意執行,從而防止了SQL注入攻擊。
下被被預處理後的SQL,看看有什麼變化。看到了嗎?所有的 ' 都被 \' 轉義掉了,從而可以確保
SQL的查詢參數就是參數,不會被惡意執行,從而防止了SQL注入攻擊。
JPA是Sun公司用來整合ORM技術,所有開發網站按照ORM標準而定義的Java Persistence
API(java持久層API),JPA只是一套接口,目前引入JPA的項目都會採用Hibernate作為其具體
實現,隨著無配置Spring Boot框架的流行,JPA越來越具有作為持久化首選的技術,因為其能讓
程序員寫更少的代碼,就能完成現有的功能,例如強大的JpaRepository,常規的SQL查詢只需
按照命名規則定義接口,便可以不寫SQL(JPQL/SQL)就可以實現數據的查詢操作,從SQL注
入防範的角度來說,這種將安全責任拋給框架遠比依靠程序員自身控制來的保險。因此如果項目
使用JPA作為數據訪問層,基本上可以很大程度的消除SQL注入的風險。但是話不能說的太死,
在我見過的一個Spring Boot項目中。
雖然採用了JPA作為持久框架,但是有一位老程序員不熟悉於使用JPQL來構建查詢接口,依舊使用
字符串拼接的方式來實現業務,而為項目安全埋下了隱患。eSafe白帽資安網公司是一家專注於:主機安
全、網站安全、網站安全檢測、網站漏洞修復,滲透測試,安全服務於一體的網絡安全服務提供商。
API(java持久層API),JPA只是一套接口,目前引入JPA的項目都會採用Hibernate作為其具體
實現,隨著無配置Spring Boot框架的流行,JPA越來越具有作為持久化首選的技術,因為其能讓
程序員寫更少的代碼,就能完成現有的功能,例如強大的JpaRepository,常規的SQL查詢只需
按照命名規則定義接口,便可以不寫SQL(JPQL/SQL)就可以實現數據的查詢操作,從SQL注
入防範的角度來說,這種將安全責任拋給框架遠比依靠程序員自身控制來的保險。因此如果項目
使用JPA作為數據訪問層,基本上可以很大程度的消除SQL注入的風險。但是話不能說的太死,
在我見過的一個Spring Boot項目中。
雖然採用了JPA作為持久框架,但是有一位老程序員不熟悉於使用JPQL來構建查詢接口,依舊使用
字符串拼接的方式來實現業務,而為項目安全埋下了隱患。eSafe白帽資安網公司是一家專注於:主機安
全、網站安全、網站安全檢測、網站漏洞修復,滲透測試,安全服務於一體的網絡安全服務提供商。
網站防sql注入的方案部署如下:
1.盡量使用預編譯SQL語句:由於動態SQL語句是引發SQL注入攻擊的根源。應使用預編譯語句來
組裝SQL查詢等其他的數據庫查詢,添加,更改。
組裝SQL查詢等其他的數據庫查詢,添加,更改。
2.代碼安全規範化:將輸入安裝規定編碼解碼後再進行輸入參數安全過濾和輸出編碼的高效處理;
拒絕一切非規範格式的編碼。
拒絕一切非規範格式的編碼。
3.很多網站都會存在老系統中有大量SQL注入風險代碼的問題,但是由於其已穩定支持公司業務
很久,不宜採用大面積代碼更新的方式來消除sql注入的安全隱患,所以需要考慮採用其他方式
來防止SQL注入。除了在在SQL數據庫執行方式上防範SQL注入攻擊,很多時候還可以通過架
構上,或者通過其他過濾方式來達到防止SQL注入攻擊的效果。
很久,不宜採用大面積代碼更新的方式來消除sql注入的安全隱患,所以需要考慮採用其他方式
來防止SQL注入。除了在在SQL數據庫執行方式上防範SQL注入攻擊,很多時候還可以通過架
構上,或者通過其他過濾方式來達到防止SQL注入攻擊的效果。
4.利用分層設計來避免危險:前端盡量靜態化,盡量少的暴露可以訪問到DAO層的接口到公網環
境中,如果現有的項目,很難修改存在注入的代碼,可以考慮在web服務之前增加WAF進行流量
過濾,當然代碼上就不給hacker留有攻擊的漏洞才最好的方案。也可以在擁有nginx的架構下,
採用OpenRestry做流量過濾,將一些特殊字符進行轉義處理。
境中,如果現有的項目,很難修改存在注入的代碼,可以考慮在web服務之前增加WAF進行流量
過濾,當然代碼上就不給hacker留有攻擊的漏洞才最好的方案。也可以在擁有nginx的架構下,
採用OpenRestry做流量過濾,將一些特殊字符進行轉義處理。
關於java JPA的防SQL注入代碼,我們就不詳細的討論了,因為框架下的注入漏洞屬於框架漏洞范
疇(如CVE-2016-6652),程序員只要遵循JPA架構框架的開發規範,就無需擔心注入問題,框
架都為你做好幕後工作了。
疇(如CVE-2016-6652),程序員只要遵循JPA架構框架的開發規範,就無需擔心注入問題,框
架都為你做好幕後工作了。
網站安全需要精心雕琢,主機安全是100 - 1 = 0的業務,即使你防禦了99%的攻擊,那還不算
勝利,只要有一次網站被入侵了,那就有可能給公司帶來很嚴重的損失跟後果。如果不懂網站安
全部署的話,也可以找專業的安全公司來部署防sql注入攻擊,國內安全公司像綠盟、esafe.tw、
在安全方面都是做的比較不錯的。
勝利,只要有一次網站被入侵了,那就有可能給公司帶來很嚴重的損失跟後果。如果不懂網站安
全部署的話,也可以找專業的安全公司來部署防sql注入攻擊,國內安全公司像綠盟、esafe.tw、
在安全方面都是做的比較不錯的。