多个 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 错误代码不仅是一种良好的安全实践，而且非常有用且对用户友好，且良好的配置还将定义最后机会错误处理程序，以捕获应用程序可能抛出的任何异常。

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>

如果 EJB 部署描述符包含一个或多个授予对特殊 ANYONE 角色的访问权限的方法权限，这表明未充分考虑应用程序的访问控制，或者应用程序的结构无法实现合理的访问控制限制。

示例 1：以下部署描述符授予 ANYONE 权限来调用名为 getSalary() 的 Employee EJB 方法。

<ejb-jar>
	...
	<assembly-descriptor>
		<method-permission>
			<role-name>ANYONE</role-name>
			<method>
				<ejb-name>Employee</ejb-name>
				<method-name>getSalary</method-name>
		</method-permission>
	</assembly-descriptor>
	...
</ejb-jar>

如果请求没有被其他配置的身份验证方法拒绝，Kubernetes API 服务器默认接受匿名请求。由于 API 服务器是群集的中央管理实体，攻击者可以使用匿名请求来访问保护不充分和安全敏感的服务 API。

示例 1：以下配置启动一个 Kubernetes API 服务器并通过设置 --anonymous-auth=true 标记允许匿名请求。

...
spec:
  containers:
    - command:
      - kube-apiserver
...
      - --anonymous-auth=true
...

默认情况下，Kubernetes API 服务器将审计事件写入标准输出。审计事件应记录到持久存储中。审计事件包含用于识别安全事件、监控策略违规和协助不可否认性控制的重要数据。

示例 1：以下配置在不使用 --audit-log-path 标记的情况下启动 Kubernetes API 服务器。

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

Kubernetes API 服务器是群集的中央管理实体，它接受 HTTP 基本身份验证来对用户进行身份验证。HTTP 基本身份验证已被弃用，其容易受到暴力攻击，且会在错误配置的环境中将用户凭据泄露给攻击者。

示例 1：以下配置启动 Kubernetes API 服务器并设置 --basic-auth-file=<filename>> 标记以使用 HTTP 基本身份验证。

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-apiserver
      - --basic-auth-file=<filename>
    image: example.domain/kube-apiserver-amd64:v1.6.0
    livenessProbe:
...

宽松的访问配置可能会暴露系统并扩大组织的攻击面。向公众开放的服务通常会受到恶意实体近乎持续的扫描和探测。

当发现并发布某项公开服务的零日漏洞（例如 Heartbleed）时，尤其容易出现问题。攻击者可能会主动追踪和搜索未修补和暴露的系统以进行利用。

对关键或敏感资源的不受控制的访问可能会以各种方式对组织产生重大影响，包括泄露或篡改关键数据。

对关键或敏感资源的不受控制的访问可能会以各种方式对组织产生重大影响，包括泄露或篡改关键数据。

对关键或敏感资源的不受控制的访问可能会以各种方式对组织产生重大影响，包括泄露或篡改关键数据。