Head First Servlets&Jsp 读书摘记10——【Web应用安全】

感觉还是重要且平时少关注细节的一章内容——Web应用安全，now beginning……

110、坏蛋无处不在，作为一个Web应用开发人员，得当心3种坏蛋：假冒者（Impersonator），非法升级者（Upgrader）和窃听者（Eavesdropper）（P619）；

111、servlet安全的 4 大要素：认证（抵挡假XX），授权（抵挡非法XXX），机密性和数据完整性（抵挡窃XX）（P621；

112、如果一个网站会显示其他用户输入的任意表单文本（例如用户图书评论），就可能发生“跨网站（cross-site）”攻击。（P629）；

113、servlet规范没有指出容器应该如何实现对认证数据的支持，但一般做法是容器会提供开发商特定的一个表，其中包含用户名和相关的口令和角色。一般还会提供某种方法来维护你公司特定的认证数据，通常存储在一个关系数据库或LDAP系统中。（5631P）；

114、授权第 1 步：定义角色。把开发商特定“用户”文件（tomcat的conf目录下tomcat-users.xml）中的角色映射到部署描述文件中建立的角色。

<tomcat-users>

  <role rolename="Admin" />

  <role rolename="Member" />

  <role rolename="Guest" />

  <user username="admin" password="admin" roles="Admin, Guest" />

  <user username="jim" password="kkkk" roles="Guest" />

</tomcat-users>

----------------------------------------------

web.xml中DD<security-role>元素（部署人员在DD中创建<role-name>元素，以便容器将角色映射到用户）

<security-role>

  <role-name>Admin</role-name>

  </security-role>

  <role-name>Member</role-name>

  <security-role>

  <role-name>Guest</role-name>

</security-role>

 

授权第 2 步：定义资源/方法约束（DD中<security-constraint>元素）

<security-constraint>

    <web-resource-collection>

        <web-resource-name>UpdateRecipes</web-resource-name>

 

        <url-pattern>/Beer/AddRecipe/*</url-pattern>  <!-- 定义要受约束的资源 -->

        <url-pattern>/Beer/AddRecipe/*</url-pattern>

 

        <http-method>POST</http-method>

        <http-method>GET</http-method> <!-- 对于URL模式指定的资源哪些HTTP方法是受约束的，其他未指定方法不受约束（空为所有受约束） -->

    </web-resource-collection>

 

    <auth-constrain> <!-- 列出了哪些角色可以调用受约束的HTTP方法（谁可以调用GET，POST方法）（空标记(<auth-constrain/>)拒绝所有用户） -->

       <role-name>Admin<role-name ><!-- 空或*允许所有用户 -->

    </auth-constrain>

   

    <user-data-constraint><!-- 122内容 -->

         <transport-guarantee>CONFIDENTIAL</transport-guarantee>

    </user-data-constraint>

</security-constraint>

（P632~633）；

115、不是在资源层次上建立约束。约束是建立在HTTP请求层次上。（P635）；

116、多个<auth-constrain>决战：两个不同的非空<auth-constrain>应用于同一个受限资源，那么两个<auth-constrain>元素中所有角色并集允许访问！

1）合并单个的角色名时，所列的所有角色名都允许访问。

2）角色名“*”与其他设置合并，所有人都允许。

3）空的<auth-constrain>标记与其他设置合并，所有人都不允许！

4）如果某个<security-constraint>元素没有<auth-constrain>元素，它与其他设置合并，所有人都允许。

（P639）；

117、容器看到“request.isUserInRole("角色名")”的参数时，它会首先查找一个匹配的<security-role-ref>。如果找到，就会使用这个映射，而不管硬编码的角色名是不是真的与一个<security-role>名匹配。（P643）；

118、4 种认证类型：基本（BASIC）认证，摘要（DIGEST）认证，客户证书（CLIENT-CERT）认证，表单（FORM）认证。（P645）；

119、除了表单，认证，，一旦在DD中声明了<login-config>元素，实现认证的工作就完成了！（P646）；

120、基于表单认证需要做的事情：

1）在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>

2）创建一个HTML登录表单

3）创建一个HTML错误表单（P647）；

121、保护正在传输的数据：解决之道是SSL之上HTTPS。（P650）；

122、声明方式保守地实现数据机密性和完整性，（来自114）<user-data-constraint>（P652）；

123、使用声明式认证时，客户不会直接请求登录。

1）请求一个受限资源……（容器通过DD中认出）

2）容器向客户发送一个301响应，告诉浏览器使用一个安全传输来完成请求的重定向。

3）浏览器在做一次资源请求，这次通过一个安全连接（现在用的协议是HTTPS）。

4）容器看到资源受限，而且用户未经过认证，容器开始认证过程，向浏览器发送一个401.

5）浏览器再次做这个请求（第三次了），但这次请求的首部中提供了用户登录的数据，而且请求使用一个安全连接传送。

（P655~656）；

疯狂的抄了不少东西，回头再看看，貌似也没发现有哪个比较实用的点，啊，或许还没能理解吧……:(