J2EE工程實現中常見安全問題解決對策

by fleshwound (http://www.smatrix.org)
(注：這是我們的完整設計中的一部分，其它有些部分尚要求保密，希望這個拙文能給做J2EE專案的兄弟們帶來點幫助,有任何關於JAVA安全和密碼學理論和應用的問題可以來我們的論壇:http://bbs.smatrix.org)
   近年來，隨著互連網和計算機的普及，電子商務和電子政務成為當今社會生活的重要組成部分，以網上訂購和網上線上支付的為主要功能的網店系統(Web Shop System)是目前電子商務的熱門技術。
   JAVA以它“一次編譯，處處執行”的神奇魅力和強大的安全技術支援，很快成為WEB資訊系統開發的首選語言，而J2EE就是為了WEB應用開發而誕生的。目前J2EE的應用大部份都是多層結構的, 良好的分層可以帶來很多好處，例如可以使得程式碼結構清晰，方便元件複用，可以快速適應應用的新需求。同時，JAVA還提供了強大的安全技術(例如:JCA,HTTPS,JSSA等)。對於電子商務系統而言,系統平臺的安全性和效率是其中的核心問題,而這些正好是J2EE及其相關技術的強項。

0 系統中所要使用的API及其特點介紹
該系統中主要使用的技術和特點如下:
(1)EJB :主要是作為J2EE中間層，完成商業邏輯。目前主要有三種型別的EJB: 會話 Bean (Session Bean)、實體Bean (Entity Bean)、訊息驅動的Bean（MDB）；
(2)JAAS:在J2EE 中用於處理認證和授權服務，進行資源控制；
(3)JSP和Java Servlets:用於J2EE的表示層，生成使用者介面；
(4)JDBC:用於資料庫（資源層）的連線和與資料庫進行互動；
(5)JNDI:Java命名和目錄介面,該API實際上是用來訪問J2EE的所有資源；
(6)JMS:Java訊息傳輸服務，配合MDB使用。

1 Session的安全問題與解決方案
在專案中,儲存Session一般有兩種方法，一是分別放在客戶端，一是集中放在伺服器端。在客戶端儲存Session是指將Session的狀態序列化，然後嵌入到返回給客戶的HTML頁面中。當Session中的資訊很少時，這樣實現比較容易，另外這種方法還消除了跨越多個伺服器複製狀態的問題。
　　但是在客戶端儲存Session狀態時，必須考慮到由此帶來的安全問題，因為黑客可能通過嗅探攻擊（Sniffer）獲取敏感資訊。為了不讓敏感資訊資料暴露，解決的方法是對資料進行加密或者使用HTTPS，採用SSL技術。
　　如果是要儲存大量Session狀態的應用，最好的方法是將Session狀態統一放在伺服器端。當狀態被儲存在伺服器上時，不會有客戶端Session管理的大小和型別限制。此外，還避免了由此帶來的安全問題，而且也不會遇到由於在每個請求間傳送Session狀態帶來的效能影響，但是對伺服器的效能要求比較高。網店系統的安全性要求較高，因此Session還是集中放在中間層伺服器端,同時對客戶端到伺服器端採用SSL連線。
2客戶端的快取安全設計
大部分顧客使用的WEB瀏覽器將瀏覽過的頁面快取在磁碟上，這樣我們瀏覽網頁的時候不需要重新向伺服器發出HTTP請求，對於普通的網頁不存在安全問題。但是對於需要保密的WEB應用，會帶來安全隱患和洩漏隱私，因此對於客戶端快取，也必須做適當的處理。最好的方法就是禁止使用快取，但是對於大部分顧客而言，要求在客戶端不用快取是不現實的，因此我們必須在中間層解決該問題，方法是採用Servlet過濾器技術。該技術是Servlet2.3以後才出現的，在J2EE中的應用很廣泛。要使用該技術，需要執行以下步驟：
（1）    編寫一個Servlet過濾器，實現javax.servlet.Filter介面；
（2）    修改Web.xml檔案，使容器知道過濾器在什麼時候被呼叫。
Javax.servlet.Filter主要有3個方法：
(1)init(FilterConfig cfg) :當開始使用 servlet 過濾器服務時，容器呼叫此方法一次。傳送給此方法的 FilterConfig 引數包含 servlet 過濾器的初始化引數；
(2)destroy() :當不再使用 servlet 過濾器服務時，容器呼叫此方法；
(3)doFilter(ServletRequest req, ServletResponse res, FilterChain chain): 容器為每個對映至此過濾器的 servlet 請求呼叫此方法，然後才呼叫該 servlet 本身。傳送至此方法的 FilterChain 引數可用來呼叫過濾器鏈中的下一個過濾器。當鏈中的最後一個過濾器呼叫 chain.doFilter() 方法時，將執行最初請求的 servlet。因此，所有過濾器都應該呼叫 chain.doFilter() 方法。如果過濾器程式碼中的附加認證檢查導致故障，則不需要將原始 servlet 例項化。在這種情況下，不需要呼叫 chain.doFilter() 方法，相反，可將其重定向至其它一些錯誤頁面。
如果 servlet 對映至許多 servlet 過濾器，則按照應用程式的部署描述符（web.xml）中的先後出現的次序來呼叫 servlet 過濾器。這一部分的主要程式碼如下：
//要引入的類庫
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.*;
import java.security.*;
//設定servlet過濾程式碼段
public class CacheFilter implements Filter {
protected FilterConfig filterConfig;
private String cachetp;
//初始化
public void init(FilterConfig filterConfig) throws ServletException
{
  this.filterConfig = filterConfig;
  cachetp=config.getInitParameter("CacheControlType");
  if (cachetp==null)
  {
  throw new  ServletException("沒有定義Cache控制型別");
  }
}
//
public void destroy()
{
  this.filterConfig = null;
}
//執行過濾器部分
public void doFilter(ServletRequest request,ServletResponse response,FilterChain chain)
throws IOException, ServletException {
  if (response instanceof HttpServletResponse )
  {
      HttpServletResponse resp=(HttpServletResponse) response;
      resp.addHeader("Cache-Control",cachetp);
  }
  else
  {
    throw new  ServletException("非法相應!");
  }
    chain.doFilter(request, response);
  }


}
以下是在Web.xml中新增的對應的內容


  CacheFilter
  CacheFilter
  Cache filter
  
    CacheControlType
    no-store
  
  

  CacheFilter
  /cachecontrol

3檢視訪問的安全設定
　　所有使用者都必須登陸，只有登陸才可以看到使用者的角色和許可權相對應的檢視。因此一個重要的問題就是如何防止一個檢視或者部分的檢視被一個未被授權的客戶直接訪問。
　　在一些情況下，資源被限制為完全不允許某些使用者訪問,例如：管理後臺就不應該讓普通顧客會員訪問。有幾個方法可以做到這一點。一個方法是加入應用邏輯到處理控制器或者檢視的程式中，禁止某些使用者訪問。另一個方案是設定執行時的系統，對於一些資源，僅允許經由另一個應用資源內部呼叫。在這種情形，對於這些資源的訪問必須被通過另一個表現層的應用資源進行，例如一個servlet控制器。對於這些受限制的資源不允許通過瀏覽器直接呼叫。
　　在J2EE中，可以利用Web容器中內建的安全技術來進行角色訪問資源的控制。根據最新版本的servlet和EJB規範，安全限制在web.xml的配置描述檔案中描述，我們可以通過配置web.xml來控制角色訪問，修改配置描述檔案web.xml就可以達到快速修改安全策略的目的。
　　安全限制允許使用程式設計的方法根據使用者的角色來控制訪問。資源可以被某些角色的使用者訪問，同時禁止其它的角色訪問。另外，某個檢視的一部分也可以根據使用者的角色來限制其訪問。如果某些資源完全不允許來自於瀏覽器的直接訪問，那麼這些資源可以配置只允許一些特殊的安全形色訪問，而這些安全形色不分配給任何一個使用者。這樣只要不分配這個安全形色，那麼以這種方式配置的資源將禁止所有的瀏覽器直接訪問。下面一個例子就是web.xml配置檔案的一部分，它定義了一個安全的角色以限制直接的瀏覽器訪問。角色的名字是“vip”，受限制資源的名字是specialgood1.jsp、specialgood2.jsp、specialgood3.jsp和bookinfo.jsp。除非一個使用者或者組被分配到“vip”角色，否則這些客戶都不可以直接訪問這些JSP頁面。不過，由於內部的請求並不受這些安全的限制，一個初始時由某servlet控制器處理的請求將會導向到這些受限制的頁面，這樣它們就可以間接訪問這些JSP頁面。
    ＜security-constraint＞
    ＜web-resource-collection＞
    ＜web-resource-name＞specialgood ＜/web-resource-name＞
    ＜description＞special good infomation＜/description＞
    ＜url-pattern＞/shop/jsp/a1/specialgood1.jsp＜/url-pattern＞
    ＜url-pattern＞/shop/jsp/a1/specialgood2.jsp＜/url-pattern＞
    ＜url-pattern＞/shop/jsp/a1/specialgood3.jsp＜/url-pattern＞
＜url-pattern＞/shop/jsp/a1/bookinfo.jsp＜/url-pattern＞
    ＜http-method＞GET＜/http-method＞
    ＜http-method＞POST＜/http-method＞
    ＜/web-resource-collection＞
    ＜auth-constraint＞
    ＜role-name＞vip＜/role-name＞
    ＜/auth-constraint＞
    ＜/security-constraint＞
3 各層次間的耦合問題與解決策略
　　表現層的資料結構，例如HttpServletRequest，應該被限制在表現層上。如果將這些細節放到其它層(主要是業務邏輯層)中，將大大降低了程式碼的的重用性，令程式碼變得複雜，並且增加了層間的耦合。解決方法一個常用方法是不讓表現層的資料結構和商業層共享，而是拷貝相關的狀態到一個更常見的資料結構中再共享。你也可以選擇由表現層資料結構中將相關的狀態分離出來，作為獨立的引數共享。另外在域物件暴露表現層的資料結構，如果將諸如HttpServletRequest的請求處理資料結構和域物件共享，這樣做也會增加了應用中兩個不同方面的耦合。域物件應該是可重用的元件，如果它們的實現依賴協議或者層相關的細節，它們可重用性就很差，同時維護和除錯高耦合的應用更加困難。成熟的解決方案是不通過傳送一個HttpServletRequest物件作為一個引數，而是拷貝request物件的狀態到一個更為常用的資料結構中，並且將這個物件共享給域物件。你也可以選擇由HttpServletRequest物件中將相關的狀態分離出來，並且將每一個的狀態作為一個獨立的引數提供給域物件。
4 EJB的安全設計與控制
EJB的執行過程一般是這樣的：(1)客戶端通過JNDI檢索Home物件的引用；(2)JNDI返回Home物件的引用；(3)請求建立一個新的EJB物件；(4)建立EJB物件；(5)返回EJB物件；(6)呼叫商務方法；(7)呼叫Enterprise Bean.引起EJB的安全問題原因主要存在三個方面:
(1)用包嗅探器(Packet Sniffer)獲取使用者憑證資訊並直接呼叫會話Bean；（2）對實體Bean進行未授權訪問；（3）對訊息驅動的Bean的無效訪問(釋出惡意或者虛假的訊息).
以上安全問題可導致客戶端或者服務端欺騙攻擊和DDOS攻擊。解決問題(1)的方法是使用JAVA中SSL技術來保護通訊，解決(2)的方法是對於實體Bean全部採用本地介面或者採用JAAS(文獻[1])，對於(1)和(2)，我們可以同時採取以下措施：讓容器完成認證並傳輸使用者憑證資訊,另外使用宣告性或者程式設計的安全驗證角色。對於問題(3),J2EE並沒有提供一個很好的方案，我們的解決方案是採用數字簽名技術來保證資訊來自可信任的源。該方法的結合程式碼簡要說明如下,訊息採用JMS傳遞：
//客戶端，要用到訊息傳送者的私鑰進行簽名
...
message.setString("userid",userid);
message.setString("useritem",useritem);
message.setInt("usersn",serialnum);//包含一個序列號
message.setString("usercertid",certid);
String signature=getSignature(userid+":"+useritem+":"+serialnum+":"+certid);
//進行簽名,其中getSignature為簽名函式，要用到訊息傳送者的私鑰進行簽名，具體密碼學技術可參考文獻[2]；
message.setString("signature",signature);
sendmessage(message);//傳送資訊
...
//伺服器端
String checkstr=userid+":"+message.getString("useritem")+":"+
message.getInt("usersn")+":"+usercertid;
boolean b_check=checkSignature(checkstr,msg.getString("signature"),
usercertid,userid);
//進行驗證,其中checkSignature為驗證函式，要用到訊息傳送者的公鑰進行驗證，具體密碼學技術可參考文獻[2]；
5 CA中心與證照的生成
前面我們已經提出在客戶端要使用HTTPS和SSL,因此要建立一個自己的CA中心來管理分發證照,加強客戶端到中間層伺服器端通訊的安全性.建立CA中心的第一步是利用JAVA工具包中的Keytool生成一個X509證照,然後將該證照交由權威CA中心Vertsign簽名,再將該證照設定為根證照,建立自己的CA.每次有新使用者註冊交易的時候，都必須簽發一個使用者獨一無二的證照，關鍵的過程是如何簽發證照.簽發證照的過程如下：
(1)從中間層CA伺服器的金鑰庫中讀取CA的證照：
FileInputStream in=new FileInputStream(ShopCAstorename);
        KeyStore ks=KeyStore.getInstance("JKS");
        ks.load(in,storepass);
        java.security.cert.Certificate c1=ks.getCertificate(alias);
(2)獲得CA的私鑰：
PrivateKey caprk=(PrivateKey)ks.getKey(alias,cakeypass);
(3)從CA的證照中提取簽發者資訊：
byte[] encod1=c1.getEncoded();
        X509CertImpl shopcimp1=new X509CertImpl(encod1);
        X509CertInfo shopcinfo1=(X509CertInfo)shopcimp1.get(X509CertImpl.NAME+
"."+X509CertImpl.INFO);
        X500Name issuer=(X500Name)shopcinfo1.get(X509CertInfo.SUBJECT+
"."+CertificateIssuerName.DN_NAME);
(4)獲取待簽發的證照相關資訊，與（3）類似；
(5)設定新證照的有效期、序列號、簽發者和簽名演算法：
//設定新證照有效期為1年
       Date begindate =new Date();
       Date enddate =new Date(begindate.getTime()+3000*24*360*60*1000L);            CertificateValidity cv=new CertificateValidity(begindate,enddate);
       cinfo2.set(X509CertInfo.VALIDITY,cv);
     //設定新證照序列號
       int sn=(int)(begindate.getTime()/1000);
       CertificateSerialNumber csn=new CertificateSerialNumber(sn);
       cinfo2.set(X509CertInfo.SERIAL_NUMBER,csn);
       //設定新證照籤發者
       cinfo2.set(X509CertInfo.ISSUER+"."+
CertificateIssuerName.DN_NAME,issuer);
          //設定新證照演算法
       AlgorithmId algorithm =
new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid);
       cinfo2.set(CertificateAlgorithmId.NAME+
"."+CertificateAlgorithmId.ALGORITHM, algorithm);
(6)建立證照並簽發：
// 建立證照
        X509CertImpl newcert=new X509CertImpl(cinfo2);
        // 簽名
        newcert.sign(caprk,"MD5WithRSA");
(7)將新證照提供給註冊使用者，並提示安裝,一般的做法是在使用者註冊成功後系統立即返回一個證照物件給中間層某個Servlet，由其返回給使用者。
                      參考文獻
[1]沈耀,陳昊鵬,李新顏.EJB容器中基於JAAS 的安全機制的實現.[J]:計算機應用與軟體 2004.9 16~18
[2](美)Jess Garms著，龐南等譯. Java安全性程式設計指南[M].北京:電子工業出版社 2002
[3] http://java.sun.com/j2ee/
[4] 蔡劍,景楠. Java 網路程式設計：J2EE（含1.4最新功能）[M].北京: 清華大學出版社 2003
[5](美)John Bell Tony Loton. Java Servlets 2.3程式設計指南[M].北京: 電子工業出版社 2002
[6](美)Joseph J.Bambara等著,劉堃等譯. J2EE技術內幕[M].北京:機械工業出版社 2002
[7](美)Li Gong著.JAVA 2平臺安全技術——結構、API設計和實現[M].北京: 機械工業出版社 2000
[8](英)Danny Ayers等著,曾國平等譯. Java伺服器高階程式設計[M].北京：機械工業出版社 2005
[9]http://www.smatrix.org/bbs
[10]http://www.smatrix.cn/bbs
(歡迎轉載，但需保留作者資訊！－by felshwound)

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=740484