高级安全注意事项
简介
第 1 部分 解释了 IBM WebSphere Application Server V7.0 和更高版本在设计时如何考虑到默认安全性安全原则。目标是在最常见的配置和比较简单的环境中，让这个产品在默认情况下具有合理的安全水平（尽管这个目标还没有完美地实现）。前一篇文章最后介绍了 WebSphere Application Server 中已经采用的许多重要的基于基础架构的预防性安全措施。本文将介绍基于应用程序的其他预防性措施，然后讨论一些重要的注意事项。
尽管本文中的信息基于 IBM WebSphere Application Server V7、V8.0 和 V8.5，但是讨论的大多数问题同样适用于 V6.1。对于某个版本特有的问题，我们会专门指出。如果您使用以前的 WebSphere Application Server 版本，请参考 早期文章，因为具有显著的版本差异，这些差异进而会导致文章之间的差异。
配置文件备注
如果熟悉 V8.5 之前的 WebSphere Application Server，您就会知道必须要创建一个或多个配置文件。该配置文件可能是一个 Application Server（或 Base）配置文件、一个 Deployment Manager 配置文件等。在本文的剩余部分中，这些配置文件被称为 “完整” 配置文件。进行这样的区分是为了将这些配置文件与 V8.5 中新增的配置文件（Liberty 配置文件）进行对比。本文还提供了特定于新的 Liberty 配置文件的一些建议。
基于应用程序的预防性措施
配置措施
到目前为止，本文的重点是介绍创建安全的 IBM WebSphere Application Server 基础架构可以采取的基本步骤。这显然很重要，但只关注基础架构是不够的。既然基础架构已经加强了，那么现在有必要研究一下应用程序需要做哪些事情来确保安全性。当然，应用程序必须利用 WebSphere Application Server 提供的基础架构，但应用程序开发人员还必须执行（或避免）其他一些操作来尽可能地提高应用程序的安全性。
不要将 Web 服务器的文档根设置为 WAR
仔细检查每个 servlet 别名是否安全
不要通过类名提供 servlet
不要将敏感信息放在 WAR 根目录中
定义默认的错误处理程序
考虑禁用文件服务和目录浏览
启用会话安全性
注意定制的 JMX 网络访问
为了帮助您将这些措施与特定的攻击类别联系起来，每个措施都使用了 第 1 部分 介绍的标记来表示攻击的类别。
1. 不要将 Web 服务器的文档根设置为 WAR
WAR 文件包含应用程序代码和大量敏感信息。其中只有一部分信息可以向 Web 提供的内容。因此，将 Web 服务器文档根设置为 WAR 根目录是不合适的。如果这样做，Web 服务器会不加解释地提供 WAR 文件的所有内容。这会导致将代码、未经处理的 JSP 和其他内容提供给最终用户。（这项措施只在 Web 服务器和应用程序服务器放在一起时才有用，如果您遵循 第 1 部分 中给出的指南，通常不会出现此情况。）
2. 仔细检查每个 servlet 别名是否安全
WebSphere Application Server 通过 URL 保护 servlet。每个要保护的 URL 都必须在描述应用程序的 web.xml 文件中指定。如果 servlet 不止有一个别名（也就是说，多个 URL 访问相同的 servlet 类），或者有许多 servlet，那么很容易遗忘对某个别名的保护。需要谨慎处理这一点。由于 WebSphere Application Server 保护的是 URL，而不是底层类，所以即使只有一个 servlet URL 是不安全的，入侵者也能够绕过您的安全措施。为了减少这种威胁，应该尽可能地使用通配符来保护 servlet。如果那样做不合适，则应该在部署前再次仔细检查 web.xml 文件。
APAR PK83258（在 WebSphere Application Server Versions 7.0.0.7 和 6.1.0.27 中）会像对待 GET 请求那样检查 HEAD 请求的授权，从而在一定程度上堵住了这个漏洞。
在为 servlet 指定授权约束时，要确保不列出任何方法，或者非常仔细地列出 servlet 的所有方法（很可能在多个约束中），比如 GET、POST、PUT、HEAD 等。对于每个 Java EE 规范，如果授权约束显式地列出方法，没有提到的方法就没有授权约束！这对于 HEAD 等方法尤为危险，HEAD 在默认情况下通过调用 GET 获取所需的标头，这实际上会调用 GET 方法，但不会检查它的授权约束。清单 1 中的 web.xml 代码是不安全的，而清单 2 中的代码是安全的。
清单 1. web.xml – 不安全
<security-constraint>
<web-resource-collection>
<web-resource-name>myservlet</web-resource-name>
<url-pattern>/myservlet</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>arole</role-name>
</auth-constraint>
</security-constraint>
清单 2. web.xml – 安全
<security-constraint>
<web-resource-collection>
<web-resource-name>myservlet</web-resource-name>
<url-pattern>/myservlet</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>arole</role-name>
</auth-constraint>
</security-constraint>
下面的方法可从每个 web.xml 中获取，以确保权限是受限的：
定义一个初步安全约束，比如清单 3 中所示的约束。这表明所有 URL（除非被更具体的模式覆盖）仅限于 NoAccess 角色。NoAccess 角色名称可预先绑定到 None 特殊角色。
清单 3
<security-constraint>
<web-resource-collection>
<web-resource-name>DefaultDeny</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>NoAccess</role-name>
</auth-constraint>
</security-constraint>
如果使用基于表单的登录，则应定义宽松的约束，允许 Web 容器向任何用户显示登录页面（和必要的图形等），甚至未经过身份验证的用户也能看到这些（清单 4）。AllUsers 角色名称可预先绑定到 Everyone 特殊角色。
清单 4
<security-constraint>
<web-resource-collection>
<web-resource-name>LoginForm</web-resource-name>
<url-pattern>/Login.jsp</url-pattern>
<url-pattern>/images/*.gif</url-pattern>
<url-pattern>/css/*.css</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>AllUsers</role-name>
</auth-constraint>
</security-constraint>
查看本栏目更多精彩内容：http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索文件
， 安全
， server
， application
， websphere
， 配置
， xml高级配置
java基础加强
websphere8.5下载、websphere8.5安装包、websphere8.5下载地址、websphere 8.5、websphere8.5安装部署，以便于您获取更多的相关知识。