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---随笔十