感觉还是重要且平时少关注细节的一章内容——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);
疯狂的抄了不少东西,回头再看看,貌似也没发现有哪个比较实用的点,啊,或许还没能理解吧……:(