首页 > 代码库 > 《Head First Servlets & JSP》-12-Web应用安全
《Head First Servlets & JSP》-12-Web应用安全
serlvet安全的4大要素
认证、授权、机密性和数据完整性。
容器完成认证和授权的过程
代码中不要有安全信息
大多数Web应用,大多数情况下Web应用的安全约束都应该以声明方式处理,即在部署描述文档中指定。原因如下:
谁不想更多地采用XML呢
通常能自然地映射到公司IT部门现有的任务角色
你可以用更灵活的方式使用以前servlet
应用开发人员可以重servlet不用去碰源代码
随着应用的扩展,可以减少可能的维护
还有一点,这正好能体现容器的价值
支持基于组件的开发思想
谁来实现Web应用中的安全?
-servlet提供者只需要关注业务
- 应用管理员只需要确定应用中有哪些角色(如tomcat中的conf/tomcat-users.xml)
- 主要任务由部署人员承担:确定哪些角色可以访问哪些servlet
授权的步骤
- 安全领域
安全领域即存储认证信息的地方,如tomcat的tomcat-users.xml会在启动时读入内存,则成为内存领域。(测试时可以在该文件存放角色认证信息,生产环境则一般不推荐,而是用LDAP或关系数据库存放)。 - tomcat-users.xml文件
- 启动认证
要让容器询问用户名和口令,需要在DD中如下配置,才能进行认证:
授权第一步:定义角色
把开发商(Tomcat)特定的“用户”文件的角色映射到部署描述文件中建立的角色。
如开发商特定的tomcat-users.xml中的role元素:
以及servlet规范:web.xml中的DD security-role元素:
授权第二步:定义资源/方法约束security-constraint
以声明的方式指定一个给定的资源/方法组合中能由特定角色的用户所访问。
在DD的security-constraint元素:
关于security-constraint子元素web-resource-collection的要点:
<web-resource-collection>元素有两个主要的子元素:url-pattern(一个或多个)和http-method(可选,0个或多个);
URL模式和HTTP方法一同定义受限资源请求;
web-resource-name元素是必要的,就算你自己可能不会用它(可以认为它要由IDE使用,或留待将来使用);
description元素是可选的;
url-pattern元素使用servlet标准命名和映射规则(有关URL模式的详细内容可以去看关于“部署’那一章);
必须至少指定一个url-pattern,不过也可以有多个;
http-method元素的合法方法包括:GET、POST、PUT、TRACE、DELETE、HEAD和OPTIONS;
如果没有指定任何HTTP方法,那么所有方法都是受约束的!!;
如果确实指定了http-method,则只有所指定的方法是受约束的。换言之,一旦指定了一个http-method,就会自动使未指定的HTTP方法不受约束;
一个security-constraint中可以有多个web-resource-collection元素;
auth-constraint元素应用于security-constraint中的所有web-resource-collection元素。
auth-constraint元素并不是定义哪些角色可以访问web-resource-collection中的资源,相反,它只是定义了哪些角色可以做出受约束的请求。
关于security-constraint子元素auth-constraint子元素:
auth-constraint规则:
在security-constraint元素中,auth-constraint元素是可选的;
如果存在一个auth-constraint,容器必须对相关URL进行认证;
如不存在auth-constraint,容器运行不经认证就能访问这些URL;
为提高可读性,可以在auth-constraint中增加一个description元素。
role-name规则:
在auth-constraint元素中,role-name元素是可选的;
如果存在role-name元素,它们会告诉容器哪些角色得到许可;
如果存在一个auth-constraint元素,但是没有任何role-name子元素,那么所有用户都遭到拒绝;
如果有<role-name>*</role-name>,那么所有用户都是允许的;
角色名区分大小写。
多个security-constraint/auth-constraint元素的对决
`
- 合并单个的角色名时,所列的所有角色名都允许访
问; - 角色名“*”与其他设置合少t–时,所有人都允许访
问; - 空的(空的不是没有)auth-constraint标记与其他设置合并时,所有人都不允许访问!换句话说,空的auth-constraint就是最后“宣判”!
- 如果某个security-constraint素没有auth-constraint元素,它与其他设置合并时,所有人都允许访问。
`两个不同的非空auth-constraint元素应用于同一个受限资源,那么两个auth-constraint元素中所有角色的并集都运行访问。
受限访问,指的是客户不能访问,但是Web应用的其他部分时可以的。
看看认证
- 4中认证类型
基本认证、摘要认证、客户证书认证和表单认证。 - 实现认证
在DD中声明认证机制,主要是login-config元素
认证类型小结
基于表单的认证
表单登录,可以定制自己的登录表单页面,而不是用其他3中认证所有的浏览器登录窗口。
表单登录安全保证:HTTPS
要实现数据机密性和/或完整性时,J2EE规范可以保证所传输的数据会经过一个“有保护的传输层连接”,即容器不必使用任何特定的协议来处理安全传输。(实际中几乎都会使用SSL之上的HTTPS协议。)
数据保护要有一些开销,且不会对应用中的每个请求和响应都加密,因此使用——以声明方式保守地实现数据机密性和完整性:
数据保护
- 未经认证的客户请求一个没有传输保证的受限资源
- 未经认证的客户请求一个受限资源,这个资源有机密性传输保证
《Head First Servlets & JSP》-12-Web应用安全