首页 > 代码库 > 《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元素的对决

`

  1. 合并单个的角色名时,所列的所有角色名都允许访
    问;
  2. 角色名“*”与其他设置合少t–时,所有人都允许访
    问;
  3. 空的(空的不是没有)auth-constraint标记与其他设置合并时,所有人都不允许访问!换句话说,空的auth-constraint就是最后“宣判”!
  4. 如果某个security-constraint素没有auth-constraint元素,它与其他设置合并时,所有人都允许访问。
    `

    两个不同的非空auth-constraint元素应用于同一个受限资源,那么两个auth-constraint元素中所有角色的并集都运行访问。
    受限访问,指的是客户不能访问,但是Web应用的其他部分时可以的。
    技术分享

看看认证

  • 4中认证类型
    基本认证、摘要认证、客户证书认证和表单认证。
  • 实现认证
    在DD中声明认证机制,主要是login-config元素
    技术分享

认证类型小结

技术分享

基于表单的认证

表单登录,可以定制自己的登录表单页面,而不是用其他3中认证所有的浏览器登录窗口。
技术分享

表单登录安全保证:HTTPS

要实现数据机密性和/或完整性时,J2EE规范可以保证所传输的数据会经过一个“有保护的传输层连接”,即容器不必使用任何特定的协议来处理安全传输。(实际中几乎都会使用SSL之上的HTTPS协议。)
数据保护要有一些开销,且不会对应用中的每个请求和响应都加密,因此使用——以声明方式保守地实现数据机密性和完整性:
技术分享

数据保护

  • 未经认证的客户请求一个没有传输保证的受限资源
    技术分享
  • 未经认证的客户请求一个受限资源,这个资源有机密性传输保证
    技术分享

《Head First Servlets & JSP》-12-Web应用安全