javascript
Head First JSP---随笔九(Web应用安全)
要保密，要安全
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世界中如何認證
再看看容器如何完成認證和授權
容器要做的事情
以聲明方式處理安全
十大原因：
serlvet安全中的重要任務
提供表格：
| 認證 | 管理員 | 中 | 高 | 中 |
| 授權 | 部署人員 | 高 | 高 | 高 |
| 機密性 | 部署人員 | 低 | 低 | 低 |
| 數據完整性 | 部署人員 | 低 | 低 | 低 |
授權
第一步，定義角色
把開發商特定“用戶”文件中的角色映射到部署描述文件中建立角色。
開發商特定：
tomcat-users.xml中的<role>元素
**在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的要點
auth-constraint子元素的規則
<role-name>規則：
<auth-constraint>規則
多個security-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種類型的認證：
基于表單的認證
要做的事情：
如下：
DD中：
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>的合法值：
本章完，說實話，這一章沒太看明白，改天再改這篇吧。去做做實戰的安全項目先！
總結
以上是生活随笔為你收集整理的Head First JSP---随笔九(Web应用安全)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 试用期这样做更快通过
- 下一篇： Head First JSP---随笔十