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世界中如何认证

这里写图片描述


再看看容器如何完成认证和授权

这里写图片描述


容器要做的事情

这里写图片描述


以声明方式处理安全

十大原因:

  1. 支持基于组件的开发思想。
  2. 体现容器的价值。
  3. 随着应用的扩展,可以减少可能的维护。
  4. 允许应用开发人员重用servlet,而不用去纠结源代码。
  5. 考试中会考。
  6. 可以用更灵活的方式使用以前写的servlet。
  7. 让简历更出色。
  8. 通常能自然的映射到公司IT部门现有的任务角色。
  9. 更多XML练习。
  10. 这样很酷

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的要点

  1. <web-resource-collection>元素有两个主要的子元素:<url-pattern>(一个或多个)和<http-method>(可选,0或多个)。
  2. URL模式和HTTP方法共同定义受限资源请求,这些资源只能由<auth-constraint>中定义的角色访问。
  3. <web-resource-name>元素是必要的(尽管你自己可能不会用到它)。
  4. <description>元素是可选的。
  5. <url-pattern>元素使用servlet标准命名映射规则
  6. 必须至少指定一个<url-pattern>
  7. <http-method>元素的合法方法包括GET、POST、PUT、TRACE、DELETE、HEAD和OPTIONS。
  8. 如果没有指定任何HTTP方法,那么所有方法都是受约束的(这表示,它只能由<auth-constraint>中定义的角色访问)。
  9. 如果确实指定了<http-method>,那么只有所指定的方法是受约束的,换句话说,一旦指定了一个<http-method>,就会使未指定的HTTP方法自动启用(即不受约束)。
  10. 一个<security-constraint>中可以有多个<web-resource-collection>元素。
  11. <auth-constraint>元素应用于<security-constraint>中的所有<web-resource-collection>元素。

auth-constraint子元素的规则

<role-name>规则:

  1. <auth-constraint>元素中,<role-name>元素是可选的。
  2. 如果存在<role-name>元素,它们会告诉容器哪些角色得到许可。
  3. 如果存在一个<auth-constraint>元素,但是没有任何<role-name>元素,那么所有用户都遭拒绝。
  4. 如果有<role-name>*</role-name>那么所有用户都是允许的。
  5. 角色名区分大小写。

<auth-constraint>规则

  1. <security-constraint>元素中,<auth-constraint>元素是可选的。
  2. 如果存在一个<auth-constraint>,容器就必须对相关的URL完成认证。
  3. 如果不存在<auth-constraint>,容器允许不经认证就能访问这些URL。
  4. 为了提高可读性,可以在<auth-constraint>中增加一个<description>
  5. 如果是没有<auth-constrain>标记,那么所有人都可以访问被约束的URL;如果是单标签<auth-constraint />的话,那么谁都不能访问被约束的URL。

多个security-constraint的规则

  1. 合并单个的角色名是,所列的所有角色名都运行访问。
  2. 角色名“*”与其他设置合并时,所有人都允许访问。
  3. 空的<auth-constraint/>标记与其他设置合并时,所有人都不允许访问!换句话说,空的<auth-constraint>就是最后“宣判”。
  4. 如果某个<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种类型的认证:

  1. 基本(BASIC)认证以一种编码形式(未加密)传输登录信息。听上去可能很安全,但是你可能已经知道了,由于编码机制(base64)已经广为人知,所以基本认证的安全性很弱。
  2. 摘要(DIGEST)认证以一种更为安全的方式传输登录信息,但是由于加密机制没有得到广泛使用,并不要求J2EE容器一定要支持摘要认证。
  3. 客户证书(CLIENT-CERT)认证以一种非常安全的形式传输登录信息,它使用了公共密钥证书(PKC)。这种机制的缺点是,你的客户必须先有一个证书才能登录你的系统。客户很少有证书,所以客户证书认证主要用于B2B应用。
  4. 表单(FROM)认证允许你利用合法的HTML建立自己的定制登录表单。表单会以最不安全的方式传输。

基于表单的认证

要做的事情:

  1. 在DD中声明<login-config>
  2. 创建一个HTML登录表单
  3. 创建一个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>的合法值:

  1. NONE,默认值,意味着没有数据保护。
  2. INTEGRAL,数据在传输过程中不能更改。
  3. CONFIDENTIAL,数据在传输过程中不能被别人看到。

本章完,说实话,这一章没太看明白,改天再改这篇吧。去做做实战的安全项目先!

猜你喜欢

转载自blog.csdn.net/qq_37340753/article/details/81452368