在J2EE Web 應用中使用基于CAPTCHA 的授權模塊

2019-11-18 12:40:56

字體：大中小

來源：轉載

供稿：網友

　　Web應用的前景是在不斷的演進中的，它已經從最開始作為共享文檔和信息的方式演化為業務治理的平臺，而在這種應用中，許可和授權是一個要害的特征。Web的應用前景還在不斷的演進中，而本文把關注放在面向群體的應用中，例如博可和維基。在這種應用中，由于作者希望有交流和反饋，所以授權不是非常嚴格的。有時，由于害怕識別，會造成失去一些人可能做出的貢獻。但是，缺少授權就會帶來諸如垃圾郵件這類的問題。這里有幾條在Web上抽取的信息：

　　·我認為在維基上垃圾郵件是不可避免的。我建立了這個網站維基的一部分，把修改權限
平開放給每個人，以鼓勵讀者和來訪者互相交流。但是，這已經是第二次了，一個發垃圾郵件的人把一堆到中國網站的鏈接放在這的網頁里。（摘自X-Pollen）

　　·“致所有在維基上發垃圾郵件的人：從1-2-2005起，任何人要做任何操作，包括編輯或增加新頁，都要由搜索引擎強制間隔十個小時。由于在這個網站上發的垃圾郵件在一分鐘、最多一小時內就會被刪除，所以，任何試圖在這個網站上建立發垃圾郵件的機制都是徒勞的舉動。（摘自C2 Wiki）”

　　很明顯，垃圾郵件發送源必須被識別出來。大多數者類惡意的攻擊發生數據匹配模式被識出來之后。一個可能的方法是人工而不是有計算機來停止這種攻擊，很顯然這是個挑戰。通過圖靈測試，按一個有名的計算機專家――阿蘭。圖靈命名的試驗，可以確定機器能夠實現類似人類操作的能力。者類測試中最有名的一個是CAPTCHA (an acronym for completely automated public Turing test to tell computers and humans apart)。這個測試常用來表明以個典型的情況：混亂或含義模糊的詞，人很輕易識別，但對于光學識別軟件來講卻很困難。

　　圖1是一個典型的CAPTCHA.

在J2EE Web 應用中使用基于CAPTCHA 的授權模塊（圖一）

　　圖1一個典型的CAPTCHA.

　　現在，大多數主要的服務提供商(Yahoo, Hotmail, Google)已經在他們的免費服務中使用CAPTCHA，用來作為區分垃圾郵件和虛假注冊的手段。在本文中，我們要描述以下在我們的Web應用中加入基于CAPTCHA授權的方法。

　　首先，我們快速瀏覽以下J2EE中Web應用的安全模型。

　　J2EE安全模型

　　在java開發中，安全性始終是一個最受關注的領域。毫無疑問，J2EE在構建安全的應用時，采用了同樣的原理和健壯的框架。在J2EE中，安全性是一個很大的題目，在這里是不可能敘述細節的。在這方面有好多好的資源。我極力推薦團隊和個人花些時間來熟悉這些概念。在這力，我只能極概括的敘述一些最要害的概念。

　　要害概念

　　在J2EE應用中，安全性必須采用聲明或編程的話方法。就象名字中暗示的，當采用聲明方法時，開發者在應用軟件代碼的外部定義用于應用的安全性約束。這些聲明用部署描述符的形式來建造(web.xml， ejb-jar.xml)，并由容器的運行環境來保證它的強制執行。聲明的方式容許開發者：

　　·能夠實現基于身份的對資源存取的約束（例如：/admin/* 只能容許有治理員身份的人來操作）
　　·能夠實現對某些URL的存取只能用某種協議的約束（例如：“/customer/*”只能通過HTTPS來訪問）
　　·能夠實現基于身份的對某些服務存取的約束（例如：可以限定SiteShutdownServlet只能由具有“god”身份的人來操作）
　　·能夠實現當用戶要存取某些受限資源但用戶還沒有登錄到系統的時候，自動重定向到登錄頁面的功能.而編程的方法能提供查詢和調用安全設施的機制，而開發者必須實現這些機制。這個方法的特點是：
　　·檢索出與當前用戶相關聯的部分：HttpServletRequest.getUserPRincipal or EJBContext.getCallerPrincipal
　　·查詢用戶是否具有某種特定的身份：HttpServletRequest.isUserInRole(String role) or EJBContext.isCallerInRole(String role)

　　這兩種方法都有它的局限性，并且是能互相補充的。

　　Web應用的聲明安全的方法

　　Web應用的聲明安全的方法本質上是一種被動的方法。這意味者只有在剛開始訪問受保護資源的用戶，假如他們沒有被受權，才會被重定向到登錄頁面。假如這個用戶已經被授權并有適當的權限，他們就能訪問這些資源。

　　這類方法中有一個最常用的方法是基于規則的受權。應用部署描述符web.xml分兩個部分描述了在這個方法中需要的所有元素。

　　第一部分是適用于整個應用的。它要鑒別出：

　　·在登錄中需要使用的方法。J2EE支持BASIC，DIGEST，FORM，或CERT等幾種授權機制。
　　·用于基于規則受權的登錄和錯誤的頁面
　　·能在應用中使用的所有身份的超集

　　圖2表明了第一部分的要害元素和它們之間的關系

在J2EE Web 應用中使用基于CAPTCHA 的授權模塊（圖二）

　　圖2 第一部分的要害元素和它們之間的關系

　　第二部分說明了資源方面的約束。部署描述符可以包含零個或多個類似于下面的聲明：

　　·需要保護的站點。這可以在web-resource-collection內使用url-pattern來配置。
　　·能夠存取資源的身份的集合(auth-constraint)。它通常是第一部分定義的身份集合的一個子集。
　　·與某個資源相關的傳輸的保證(user-data-constraint)。

　　圖3表明了第二部分的要害元素和它們之間的關系

在J2EE Web 應用中使用基于CAPTCHA 的授權模塊（圖三）

　　圖3 第二部分的要害元素和它們之間的關系

　　現在，我們看一個簡單的例子web.xml:

<web-app>

  

  
  <security-constraint>

    
    <web-resource-collection>
      <web-resource-name>Protected Area</web-resource-name>
      <url-pattern>/admin/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
    </web-resource-collection>

    
    <auth-constraint>
      <role-name>admin</role-name>
    </auth-constraint>

    
    <user-data-constraint>
      <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>

  </security-constraint>

  
  <login-config>
    
    <auth-method>FORM</auth-method>
    <realm-name>Default Realm</realm-name>

    
    <form-login-config>
      <form-login-page>/login/login.jsp</form-login-page>
      
      <form-error-page>/login/error.jsp</form-error-page>
    </form-login-config>
  </login-config>

  
  <security-role>
    <description>Capable of administrating the site</description>
    <role-name>admin</role-name>
  </security-role>
</web-app>

　　這個簡單的部署描述符包含以下幾部分的安全配置：

　　·約束對有以/admin/*模式開頭的URLs的存?。║RLl模式）
　　·在/admin下的資源只能使用HTTP GET或POST來存取(HTTP方法)
　　·資源能在標準的HTTP連接方式下提供服務（傳輸保證）
　　·只有具有治理員身份的用戶才能存取這些資源（身份命名）
　　·對遠程用戶使用基于規則的授權（授權方法）
　　·給用戶顯示一個登錄的頁面――/login/login.jsp ，以便用戶輸入信息來確認身份（形成登錄頁面）
　　·假如在授權過程中發生錯誤，給用戶顯示以個頁面來提示出錯――/login/error.jsp（形成出錯頁面）

　　擴展一個容器的安全設施

　　JAAS（Java Authentication and Authorization Services)實現了一個JAVA應用的可插入性授權模塊（PAM）。它容許平行開發安全部分和應用部分。開發者可以從這些選項中選擇并在應用中配置。由于容許與應用平行開發，所以JAAS有一些優點，還可以促進它在不同的應用中重用。

　　JAAS在應用的服務端也同樣有價值。然而，JAAS在J2EE中并沒有取得同樣的成功。直到最近，才開放了一些可定制的API用于擴展安全設施。但情況在改變。應用的服務端現在提供了適配器，可以容許把JAAS整合近已有的安全設施。這種整合仍然是與具體的應用相關的，并且非常復雜。

　　Tomcat提供了一種使用JAAS的相當簡單和直接整合的方法。用戶登錄模塊是用配置文件來配置的（Tomcat realm configuration and the standard JAAS configuration）。當服務端需要調用登錄模塊時，它把所有的請求都路由到org.apache.catalina.realm.JAASRealm適配器。把JAAS整合進Tomact的細節可參考相應的資料Resources。

　　在這篇文章，我們實現了一個JAAS模塊，并把它整合近Tomcat服務端，以提供J2EE的安全解決方案。

　　解決方法

　　在敘述實現方面之前，先描述一下解決方案的目標和所用的方法。

　　目標：

　　·為Web應用提供一種較弱的授權機制。這里，較弱的授權機制的含義是安全模塊或應用不區分用戶是否是在遠程訪問。
　　·不要求每個用戶在系統中有惟一的一個標識（登錄名）。這可以對遠程用戶做一定的隱藏。
　　·這種授權機制能區分計算機和用戶，這樣可以防止垃圾郵件的源自動登錄并濫用資源。我們用CAPTCHAs來做測試。
　　·這個授權機制應該基于J2EE的安全模型。我們要避免與這個模型不一致的方法。

　　根據以上的目標，很顯然，我們要保證每次會話中都是由實際的用戶參與的。應用的服務端治理會話來保持用戶的狀態。當一個未授權的用戶訪問受保護的資源的時候，J2EE的安全模塊要把用戶轉到登錄頁面。這個登錄頁面產生以個惟一的CAPTCHA并把它與用戶的會話聯系起來。這個登錄頁面就以一幅圖像的形式顯示這個CAPTCHA，并要求用戶識別這幅圖像。這個登錄頁面還有一個包含當前會話ID的隱藏起來的輸入域。

　　用戶把自己識別的結果添入輸入域并提交。在得到反饋后，負責登錄的模塊取出對話的ID和用戶的反饋。然后，把反饋與這個會話相關聯的CAPTCHA相比較。假如匹配，那么這個對這個用戶的鑒別就通過了，并把這個用戶的身份定為anonymous。

　　在授權后，遠端的用戶就可以以anonymous用戶的身份來存取所有受保護的資源。

　　圖4說明了我們的方法

在J2EE Web 應用中使用基于CAPTCHA 的授權模塊（圖四）

　　圖4 我們的方法

　　實現

　　實現一個新授權機制的過程是相當明了的。整個過程可分為四個過程：

　　·保護Web資源
　　·為每個會話產生以個惟一的標識
　　·與已有的安全容器整合
　　·測試

　　下面具體敘述以下這些過程。

　　保護Web資源

　　Web資源保護用J2EE聲明安全機制。下面的是web.xml文件的一個片斷，顯示了如何實現要求的配置。

<?xml version="1.0" encoding="ISO-8859-1"?>

<web-app>

  <!-- constrain a  section of the site -->
  <security-constraint>
      <display-name>Anonymous Security Constraint</display-name>
      <web-resource-collection>
         <web-resource-name>Protected Area</web-resource-name>
         <url-pattern>/security/protected/*</url-pattern>
         <http-method>GET</http-method>
         <http-method>POST</http-method>
      </web-resource-collection>
      <auth-constraint>
         <role-name>anonymous</role-name>
      </auth-constraint>
  </security-constraint>

  <!-- Default login configuration uses form-based authentication -->

  <login-config>
      <auth-method>FORM</auth-method>
      <realm-name>Anonymous Form-Based Authentication Area</realm-name>
      <form-login-config>
        <form-login-page>/security/protected/login.jsp</form-login-page>
        <form-error-page>/security/protected/error.jsp</form-error-page>
      </form-login-config>
  </login-config>
        
  <!-- Security roles referenced by this web application -->
  <security-role>
     <role-name>anonymous</role-name>
  </security-role>

  <!-- The Usual Welcome File List -->
  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>

</web-app>