只有在与比较陈旧的系统进行通信时，J2EE 标准才允许 use of sockets，因为此时没有较高高级别的协议可用。自己编写通信协议将需要解决许多安全上的问题，包括：

— 输入信号与输出信号的比较

— 协议版本间的兼容性

— 通道安全

— 错误处理

— 网络限制（防火墙）

— 会话管理

若不经过安全专家的详细审查，自定义的通信协议将面临诸多安全隐患。

在自定义标准协议的应用过程中，也会碰到许多同样的问题。通常有很多可用的资源都可以解决与标准协议相关的各种安全问题，然而，攻击者也能获取这些资源。

J2EE 标准禁止在某些环境下使用 Web 应用程序中的线程管理，因为此时使用线程管理非常容易出错。线程管理起来很困难，并且可能还会以不可预知的方式干扰应用程序容器。即使容器没有受到干扰，线程管理通常还会导致各种难以发现的错误，如死锁、race condition 及其他同步错误等。

大多数 Web 应用程序使用会话标识符对用户进行唯一标识，标识符通常存储在 Cookie 中，采用透明方式在服务器与 Web 浏览器之间传输。


如果应用程序未将会话标识符存储到 Cookie 中，则有时会作为 HTTP 请求参数或 URL 的一部分进行传输。接受 URL 中指定的会话标识符有利于攻击者发动 Session Fixation 攻击。

在 URL 中放置会话标识符还可以增加针对应用程序发动 Session Hijacking 攻击的成功率。当攻击者控制受害者的活动会话或会话标识符后，就会发生 Session Hijacking 攻击。在实践中，Web 服务器、应用程序服务器和 Web 代理往往会存储请求的 URL。如果 URL 中包含会话标识符，也会予以记录。增加查看和存储会话标识符的位置数量将提高攻击者的攻击概率。

如果您正在使用 Tomcat 执行身份验证，Tomcat 部署描述符文件会指定一个用于身份验证的“Realm”。它类似于以下内容：

示例 1：

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

此 Realm 标签可采用一个名为 debug 的可选属性，用来指示日志级别。此数值越大，日志消息越详细。如果此调试级别设置得过高，Tomcat 会将所有用户名和密码以明文形式写入日志文件中。Tomcat JAASRealm 的相关调试消息的临界值为 3（3 或更大表示不合适，2 或更小表示合适），但该临界值会因 Tomcat 提供的 Realm 类型不同而有所不同。

在使用 Web 框架（例如，Struts 或 Spring）构建的应用程序中直接访问 Java Server Page (JSP)，此类应用程序使用操作或 Servlet 将请求委托给 JSP，这样可能会引发未处理异常和系统信息泄漏。已使用经特殊技术处理的请求将实现或配置欠佳的应用程序服务器收编至泄露源代码详细信息，例如 http://host/page.jsp%00 或 http://host/page.js%2570。更糟糕的是，如果应用程序允许用户上传任意文件，攻击者可能会利用这项机制以 JSP 的形式上传恶意代码，并请求上传的页面在服务器上执行恶意代码。

示例 1：以下示例显示了构造欠佳的安全限制，明确允许直接访问角色名称中带有“*”的 JSP，这表示允许所有用户访问相应的 Web 资源。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

安全角色重复无任何意义，因为仅应用给定安全角色的最后一个定义。
示例 1：web.xml 文件中的条目定义了两个 admin 角色。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

Servlet 映射重复无任何意义，因为当在多个 Servlet 映射中使用同一 URL 模式时，只会应用最后一个条目。

示例 1：在以下示例中，在两种不同的 Servlet 映射中使用 URL 模式 /servletA/*。

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

多个 URL 模式映射到单个 Servlet 可能表明 Servlet 执行的函数过多。

示例 1：以下示例将五个 URL 模式映射到单个 Servlet。

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

会话处于打开状态的时间越长，攻击者破坏用户帐户的机会窗口越大。会话保持活动状态期间，攻击者可以强力破解用户的密码、破解用户的无线加密密钥或控制打开的浏览器会话。如果创建足够多的会话，会话超时较长还可能阻止内存释放，最终引发 Denial of Service 攻击。

示例 1：如果会话超时为零或小于零，则会话永不过期。以下示例显示了设置为 -1 的会话超时，这将使会话无限期保持活动状态。

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

<session-timeout> 标签为 Web 应用程序中的所有会话定义了默认会话超时间隔。如果缺少 <session-timeout> 标签，则由容器设置默认超时。

当攻击者探索某个网站以寻找漏洞时，该网站提供的信息量对于任何试图攻击的最终成功或失败至关重要。如果应用程序向攻击者显示堆栈跟踪，相当于主动提供了使攻击者实现超容易攻击的信息。例如，堆栈跟踪可能会向攻击者显示格式错误的 SQL 查询字符串、正在使用的数据库类型以及应用程序容器的版本。此信息使攻击者能够针对这些组件中的已知漏洞进行攻击。

应用程序配置应指定默认错误页面，以保证应用程序永远不会将错误消息泄露给攻击者。处理标准 HTTP 错误代码不仅是一种良好的安全实践，而且非常有用且对用户友好，且良好的配置还将定义最后机会错误处理程序，以捕获应用程序可能抛出的任何异常。

如果应用程序使用 SSL 来保证与客户端浏览器的机密通信，则应用程序应配置为在没有 SSL 的情况下无法查看任何访问控制页面。

绕过 SSL 的常见方式有以下三种：

- 用户手动输入 URL 并键入“HTTP”而不是“HTTPS”。

- 攻击者故意将用户发送到不安全的 URL。

- 程序员错误地创建了指向应用程序页面的相对链接，导致不能从 HTTP 切换到 HTTPS。（当链接在网站上的公共区域和安全区域之间移动时，尤其容易出现这种情况。）

WebLogic 部署描述符应指定长度至少为 24 个字节的会话标识符。较短的会话标识符使应用程序容易受到暴力破解会话攻击。如果攻击者可以猜测出经过身份验证的用户的会话标识符，他就可以接管该用户的会话。接下来的内容将详细说明使用 24 字节会话标识符的深层合理性。

会话标识符是一个从 62 个英文或数字中产生的伪随机结果，这意味着，如果这个字符串的每一个字节都是真正随机生成的，那么它就能产生一个最大 6 比特的熵。

猜测有效会话标识符所需的预期秒数通过以下等式得出：

(2^B+1) / (2*A*S)

其中：

- B 是会话标识符中熵的比特数。

- A 是攻击者每秒可能尝试猜测的次数。

- S 是在任意指定时间内可供猜测的有效会话标识符数。

会话标识符中熵的比特数始终小于总比特数。例如，如果会话标识符按升序给出，那么不管标识符的长度如何，在会话标识符中都有接近 0 比特的熵。假设会话标识符都是通过一个正常的随机数值源产生的，我们将能估算出会话标识符中熵的比特数是总比特数的一半。现实中这样长度的标识符是有可能存在的，虽然这一看法不免可能有些乐观。

如果攻击者使用由数百或数千台计算机组成的僵尸网络 (botnet)，那么我们有理由相信他们能够完成每秒几万次的猜测。如果这个存在问题的网站规模大且受欢迎，大量的猜测行为可能在一段时间内被忽略。

可供猜测的有效会话标识符数的下限是在任意指定时间内，站点上的活动用户数量。但是，任何没有注销就丢弃会话的用户行为都将增加这个数量。（这就是为什么要设置较短的非活动会话超时时间的原因之一。）

对于一个 64 比特的会话标识符，假设有 32 比特的熵。对于一个大型网站，假设攻击者每秒可以尝试 1,000 次猜测，并且在任意给定时间内有 10,000 个有效的会话标识符。根据这些假设，攻击者成功猜测出一个有效会话标识符的预期时间少于 4 分钟。

现在假设有一个提供了 64 比特熵的 128 比特会话标识符。对于一个超大型网站，可供猜测的有效会话标识符有 100,000 个，攻击者可能尝试进行每秒 10,000 次的猜测。基于这些假设，攻击者成功破解出一个有效会话标识符的预期时间将大于 292 年。

将比特数换算成字节数，就会得出会话标识符为 128/6，即大约 21 字节。而且，实验表明，会话标识符的前三个字节不会随机产生，这就意味着，要实现所需的 64 比特熵，我们需要将 WebLogic 配置为使用一个长度为 24 字节的会话标识符。

web.xml 中缺少 Servlet 名称或 Servlet 名称重复是一项错误。每个 Servlet 都应具有唯一名称 (servlet-name) 和相应映射 (servlet-mapping)。

示例 1：web.xml 中的以下条目显示了几种错误的 Servlet 定义。

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

这些错误可能导致意外拒绝访问 Servlet。

<login-config> 元素用于配置用户如何对应用程序进行身份验证。缺少身份验证方法意味着应用程序不了解如何应用授权限制，因为任何用户都无法登录。使用 <auth-method> 标签（<login-config> 的子标签）指定身份验证方法。

共有四种身份验证方法：BASIC、FORM、DIGEST和CLIENT_CERT。

BASIC 表示 HTTP 基本身份验证。
FORM 表示基于表单的身份验证。
DIGEST 与 BASIC 身份验证类似；但是，DIGEST 会对密码进行加密。
CLIENT_CERT 要求客户端具备公钥证书并使用 SSL/TLS。

示例 1：以下配置未指定登录配置。

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

web.xml 安全限制通常用于基于角色的访问控制，但可选 user-data-constraint 元素可指定传输保证，防止采用不安全的方式传输内容。

<user-data-constraint> 标签内的 <transport-guarantee> 标签定义了通信处理方式。传输保证分为三个级别：

1) NONE 意味着应用程序不需要任何传输保证。
2) INTEGRAL 意味着应用程序要求在客户端与服务器之间发送数据期间不可在传输过程中更改数据。
3) CONFIDENTIAL 意味着应用程序要求在传输内容期间防止其他实体观察传输内容。



在大多数情况下，使用 INTEGRAL 或 CONFIDENTIAL 意味着需要 SSL/TLS。如果忽略 <user-data-constraint> 和 <transport-guarantee> 标签，则传输保证默认为 NONE。

示例 1：以下安全限制未指定传输保证。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

当攻击者探索某个网站以寻找漏洞时，该网站提供的信息量对于任何试图攻击的最终成功或失败至关重要。如果应用程序向攻击者显示堆栈跟踪，相当于主动提供了使攻击者实现超容易攻击的信息。例如，堆栈跟踪可能会向攻击者显示格式错误的 SQL 查询字符串、正在使用的数据库类型以及应用程序容器的版本。此信息使攻击者能够针对这些组件中的已知漏洞进行攻击。

应用程序配置应指定默认错误页面，以保证应用程序永远不会将错误消息泄露给攻击者。处理标准 HTTP 错误代码不仅是一种良好的安全实践，而且非常有用且对用户友好，且良好的配置还将定义最后机会错误处理程序，以捕获应用程序可能抛出的任何异常。

每个筛选器映射必须与有效筛选器定义对应才能应用。

示例 1：以下示例显示了引用不存在的筛选器 AuthenticationFilter 的筛选器映射。由于缺少定义，筛选器 AuthenticationFilter 不会应用于指定的 URL 模式 /secure/*，而且可能导致运行时异常。

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

auth-constraint 中定义的 role-name 缺少 security-role 可能表示配置过时。

示例 1：以下示例指定了 role-name，但未在 security-role 中对其进行定义。

<security-constraint>
    <web-resource-collection>
         <web-resource-name>AdminPage</web-resource-name>
         <description>Admin only pages</description>
         <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

缺少有效 Servlet 映射会阻止对未映射的 Servlet 的所有访问。

示例 1：web.xml 中的以下条目可定义 ExampleServlet，但无法定义相应的 Servlet 映射。

<web-app
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <servlet>
      <servlet-name>ExampleServlet</servlet-name>
      <servlet-class>com.class.ExampleServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
    </servlet>

</web-app>

当实体 bean 公开远程接口时，会扩大应用程序的攻击面。出于性能原因，应用程序应该很少使用远程实体 bean，因此远程实体 bean 声明很可能是一个错误。

示例 1：以下实体 bean 声明包括一个远程接口：

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>