多個 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>

開啟工作階段時間愈久，攻擊者威脅使用者帳戶的機率就愈大。工作階段仍為作用中時，攻擊者可能會暴力破解使用者密碼、破解使用者的無線加密金鑰，或是從開啟的瀏覽器控制工作階段。如果足夠大量的工作階段正在執行，較長的工作階段逾時時間也會導致無法釋放記憶體，最後造成阻斷服務。

範例 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 是工作階段識別碼中複雜度 (entropy) 的位元數。

- A 表示攻擊者每秒可能嘗試猜測的次數。

- S 是指在任何時間內可供猜測的有效工作階段識別碼數目。

工作階段識別碼中的複雜度 (entropy) 位元數比工作階段識別碼的總位元數要少。例如，如果以遞增的次序提供工作階段識別碼，則不管識別碼的長度如何，在工作階段識別碼中會有接近於 0 位元的複雜度 (entropy)。假設工作階段識別碼是使用好的隨機數字來源所產生，我們估算工作階段識別碼中複雜度 (entropy) 的位元數將是總工作階段識別碼位元數的一半。以樂觀態度來看，有可能存在此長度的識別碼。

如果攻擊者使用成千上百個受感染的電腦組成的僵屍電腦網路 (botnet)，那麼他們可進行每秒幾萬次的猜測。如果此問題網站很大而且很多人點閱，有時可能會忽略其大量的猜測行為。

可供猜測的有效工作階段識別碼數量的較低界線為，在任何時間內於網站上活動的使用者數量。不過，任何沒有登出就離開工作階段的使用者將會使此數目增加。(這就是為什麼要將未活動工作階段逾時時間設短一點的原因之一。)

使用 64 位元的工作階段識別碼，假設會有 32 位元的複雜度。對於大型網站，假設攻擊者每秒可能嘗試猜測 1000 次，並且在任何給定時間有 10000 個有效的工作階段識別碼。根據這些假設，攻擊者成功猜到有效的工作階段識別碼的預估時間大約在 4 分鐘以內。

現在假設使用 128 位元的工作階段識別碼，提供 64 位元的複雜度。對於超大型網站，攻擊者在 100000 個可猜測的有效工作階段識別碼中可以嘗試每秒 10000 次的猜測。根據這些假設，攻擊者成功猜到有效的工作階段識別碼的預估時間將超過 292 年。

將位元換成位元組，則工作階段識別碼為 128/6，大約產生 21 個位元組。此外，實驗顯示，工作階段識別碼的前三個位元組不是隨機產生的，這表示要達到想要的 64 位元的複雜度 (entropy)，我們需要將 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> 元素來設定使用者驗證至應用程式的方式。因為沒有人可以登入，沒有 authentication 方式就表示該應用程式不知道套用授權限制的方式。Authentication 方式是使用 <auth-method> 標籤進行指定，該標籤也是 <login-config> 的子項。

Authentication 方式共有四種：BASIC、FORM、DIGEST 和 CLIENT_CERT。

BASIC 代表 HTTP Basic 驗證。
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 安全性限制通常用來做為角色為基礎的 Access Control 使用，但是選用的 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 角色，這表示沒有完整考慮應用程式的 access control，或以此方式建立應用程式會使得合理的 access control 限制不可能存在。

範例 1：以下的部署描述符號授權給 ANYONE，允許其叫用 Employee EJB 的方法 getSalary()。

<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：以下組態將啟動一部 Kubernetes API 伺服器，而不使用 --audit-log-path 旗標。

...
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) 時問題特別大。攻擊者可主動追蹤和搜尋未修補和暴露的系統以進行攻擊。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。

無所克制的關鍵或敏感資源存取權，可能會以各種方式對組織產生重大影響，包括洩露或篡改關鍵資料。