要保密，要安全

Web應用危險重重。網絡的每個角落都潛伏著危險，黑客、搗亂的家伙，甚至犯罪分子會竭盡全力侵入你的系統，竊取你的秘密、利用你的信息，或者只是和你的網站開個玩笑。

---

Web應用安全

5.1 根據servlet規范，對照比較以下安全問題
1. 認證
2. 授權
3. 數據完整性
4. 機密性
5.2 在部署描述文件中聲明以下內容
1. 安全約束
2. Web資源
3. 傳輸保證
4. 登錄配置
5. 安全角色
5.3 給定認證類型(BASIC，DIGEST，FORM和CLIENT-CERT)，描述各種認證的機制

---

壞人無處不在

作為一個Web應用開發人員，你要保護好你的網站。得當心3種壞人：假冒者，非法升級者，竊聽者。

---

servlet安全的4大要素

servlet安全可以劃分為4個概念：認證、授權、機密性和數據完整性。

---

HTTP世界中如何認證

---

再看看容器如何完成認證和授權

---

容器要做的事情

---

以聲明方式處理安全

十大原因：

支持基于組件的開發思想。

體現容器的價值。

隨著應用的擴展，可以減少可能的維護。

允許應用開發人員重用servlet，而不用去糾結源代碼。

考試中會考。

可以用更靈活的方式使用以前寫的servlet。

讓簡歷更出色。

通常能自然的映射到公司IT部門現有的任務角色。

更多XML練習。

這樣很酷

---

serlvet安全中的重要任務

提供表格：

安全概念誰負責？復雜程度耗時程度對考試的重要程度

認證	管理員	中	高	中
授權	部署人員	高	高	高
機密性	部署人員	低	低	低
數據完整性	部署人員	低	低	低

---

授權

---

第一步，定義角色

把開發商特定“用戶”文件中的角色映射到部署描述文件中建立角色。

開發商特定：
tomcat-users.xml中的<role>元素

<tomcat-users><!-- 開發商特定用戶和角色數據結構 --><role rolename="Admin"/><role rolename="Member"/><role rolename="Guest"/><!-- 注意，一個用戶可能有多個角色roles --><user username="Annie" password="admin" roles="Admin,Member,Guest"><user username="Diane" password="coder" roles="Member,Guest"><user username="Ted" password="newbie" roles="Guest"> </tomcat-users>

**在web.xml中**DD<security-role>元素

<!-- 授權時，容器會把開發商特定的“角色”信息映射到DD中 --> <security-role><role-name>Admin</role-name></security-role> <security-role><role-name>Member</role-name></security-role> <security-role><role-name>Guest</role-name></security-role><!-- 別忘了，啟用認證需要配置這個 --> <login-config><auth-method>BASIC</auth-method> </login-config>

---

第二步，定義資源/方法約束

最后一步，也是最酷的一步。在這一步中，我們要以聲明方式指定一個給定的資源/方法組合，只能由特定角色的用戶訪問。

在DD中配置<security-constraint>元素：

<web-app ...><security-constraint><web-resource-collection><!-- 這個名是必要的，由工具使用。在別的地方不會看到這個名 --><web-resource-name>UpdateRecipes</web-resource-name><!-- 定義要約束的資源 --><url-pattern>/Beer/AddRecipe/*</url-pattern><url-pattern>/Beer/ReviewRecipe/*</url-pattern><!-- 描述了對于URL模式指定的資源哪些HTTP方法是受約束的 --><http-method>GET</http-method><http-method>POST</http-method></web-resource-collection><!-- 可選的，列出了哪些角色可以調用受約束的資源 --><auth-constraint><role-name>Admin</role-name><role-name>Member</role-name></auth-constraint></security-constraint> </web-app>

對于Guest來說，它不能使用GET或POST，但是可以使用TRACE、HEAD、PUT…等方法。

---

web-resource-collection的要點

<web-resource-collection>元素有兩個主要的子元素：<url-pattern>(一個或多個)和<http-method>(可選，0或多個)。

URL模式和HTTP方法共同定義受限資源請求，這些資源只能由<auth-constraint>中定義的角色訪問。

<web-resource-name>元素是必要的(盡管你自己可能不會用到它)。

<description>元素是可選的。

<url-pattern>元素使用servlet標準命名映射規則

必須至少指定一個<url-pattern>。

<http-method>元素的合法方法包括GET、POST、PUT、TRACE、DELETE、HEAD和OPTIONS。

如果沒有指定任何HTTP方法，那么所有方法都是受約束的(這表示，它只能由<auth-constraint>中定義的角色訪問)。

如果確實指定了<http-method>，那么只有所指定的方法是受約束的，換句話說，一旦指定了一個<http-method>，就會使未指定的HTTP方法自動啟用(即不受約束)。

一個<security-constraint>中可以有多個<web-resource-collection>元素。

<auth-constraint>元素應用于<security-constraint>中的所有<web-resource-collection>元素。

---

auth-constraint子元素的規則

<role-name>規則：

在<auth-constraint>元素中，<role-name>元素是可選的。

如果存在<role-name>元素，它們會告訴容器哪些角色得到許可。

如果存在一個<auth-constraint>元素，但是沒有任何<role-name>元素，那么所有用戶都遭拒絕。

如果有<role-name>*</role-name>那么所有用戶都是允許的。

角色名區分大小寫。

<auth-constraint>規則

在<security-constraint>元素中，<auth-constraint>元素是可選的。

如果存在一個<auth-constraint>，容器就必須對相關的URL完成認證。

如果不存在<auth-constraint>，容器允許不經認證就能訪問這些URL。

為了提高可讀性，可以在<auth-constraint>中增加一個<description>。

如果是沒有<auth-constrain>標記，那么所有人都可以訪問被約束的URL；如果是單標簽<auth-constraint />的話，那么誰都不能訪問被約束的URL。

---

多個security-constraint的規則

合并單個的角色名是，所列的所有角色名都運行訪問。

角色名“*”與其他設置合并時，所有人都允許訪問。

空的<auth-constraint/>標記與其他設置合并時，所有人都不允許訪問！換句話說，空的<auth-constraint>就是最后“宣判”。

如果某個<security-constraint>元素沒有<auth-constraint>元素，它與其他設置合并時，所有人都允許訪問。

總結來說，如果兩個不同的非空標記都應用于同一個受限資源，那么取兩者的并集；如果其中有一個是空的標記，那么就是所有人都不能訪問受限資源！

---

關于程序式安全

受限資源UpdateRecipe。

if(request.isUserInRole("Manager")){//處理UpdateRecipe頁面 }else{//處理ViewRecipe頁面 }

isUserInRole()方法如何工作：
（1）調用isUserInRole()前，用戶要得到認證。如果對一個未經認證的用戶調用這個方法，容器總會返回false。
（2）容器得到isUserInRole()參數，在這個例子中參數就是“Manager”，把它與請求中為此用戶定義的角色進行比較。
（3）如果用戶可以映射到這個角色，容器會返回true。

---

程序式安全也有聲明的一面

當你的程序想要將Manager換成Admin時，你不想改程序里的if中的硬編碼時，就可以使用下面這種方法，他會將硬編碼Manager改為我們所更改的admin。

在DD中：

<web-app ...><servlet><security-role-ref><role-name>Manager</role-name><role-link>Admin</role-link></security-role-ref></servlet><security-role><role-name>Admin</role-name></security-role> </web-app>

---

再看看認證

有4種類型的認證：

基本(BASIC)認證以一種編碼形式(未加密)傳輸登錄信息。聽上去可能很安全，但是你可能已經知道了，由于編碼機制(base64)已經廣為人知，所以基本認證的安全性很弱。

摘要(DIGEST)認證以一種更為安全的方式傳輸登錄信息，但是由于加密機制沒有得到廣泛使用，并不要求J2EE容器一定要支持摘要認證。

客戶證書(CLIENT-CERT)認證以一種非常安全的形式傳輸登錄信息，它使用了公共密鑰證書(PKC)。這種機制的缺點是，你的客戶必須先有一個證書才能登錄你的系統。客戶很少有證書，所以客戶證書認證主要用于B2B應用。

表單(FROM)認證允許你利用合法的HTML建立自己的定制登錄表單。表單會以最不安全的方式傳輸。

---

基于表單的認證

要做的事情：

在DD中聲明<login-config>

創建一個HTML登錄表單

創建一個HTML錯誤表單

如下：
DD中：

<login-config><auth-method>FORM</auth-method><form-login-config><form-login-page>/loginPage.html</form-login-page><form-error-page>/loginError.html</form-error-page></form-login-config> </login-config>

loginPage.html中：

<!-- j_開頭的必須存在 --> <form method="POST" action="j_security_check"><input type="text" name="j_username"/><input type="password" name="j_password"/><input type="submit" value="Enter"/> </form>

---

認證類型小結

類型規范數據完整性注釋

BASIC	HTTP	Base-64 弱	HTTP標準，所有瀏覽器都支持
DIGEST	HTTP	強一些，但不是SSL	對于HTTP和J2EE容器是可選的
FORM	J2EE	非常弱，沒有加密	允許有定制的登錄屏幕
CLIENT-CERT	J2EE	強-公共密鑰(PKC)	很強，但是用戶必須有證書

---

HTTPS輸出傳輸協議

解決了我們FORM表單沒有加密的缺點！

HTTP請求——不安全

非法竊聽者得到HTTP請求的一個副本，其中包含客戶的信用卡信息。這個數據未得到保護，所以會以一種完全可讀的形式放在POST請求的體中。

SSL請求之上的安全HTTPS
非法竊聽者得到HTTP請求的一個副本，其中包含客戶的信用卡信息。但是因為這是通過SSL之上的高安全強度HTTPS發送的，所以竊聽者無法讀懂信息！

---

如何以聲明方式保守地實現數據機密性和完整性

在DD中配置：

<web-app ...><security-constraint><web-resource-collection><web-resource-name>Recipes</web-resource-name><url-pattern>/Beer/UpadateRecipes/*</url-pattern><http-method>POST</http-method></web-resource-collection><auth-constraint><role-name>Member</role-name></auth-constraint><!-- 主要聲明是下面 --><user-data-constraint><transport-guarantee>CONFIDENTIAL</transport-guarantee></user-data-constraint><security-constraint> </web-app>

以上<security-constraint>的3個子元素放在一起可以讀作：只有Member可以對UpateRecipes目錄中找到的資源完成POST請求，而且確保數據是安全的。

<transport>的合法值：

NONE，默認值，意味著沒有數據保護。

INTEGRAL，數據在傳輸過程中不能更改。

CONFIDENTIAL，數據在傳輸過程中不能被別人看到。

---

本章完，說實話，這一章沒太看明白，改天再改這篇吧。去做做實戰的安全項目先！

總結

以上是生活随笔為你收集整理的Head First JSP---随笔九(Web应用安全)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。