要保密,要安全
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,数据在传输过程中不能被别人看到。