安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送該訊息。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

下列用戶端組態要求 Axis 2 接受未簽署時間戳記：

<axisconfig name="AxisJava2.0">
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送該訊息。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

下列用戶端組態要求 Axis 2 傳送未簽署時間戳記：

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

依預設，Azure Blob 儲存體容器會阻止匿名存取其 Blob。

存取組態不足會將系統暴露在外，並擴大組織的受攻擊面。開放公開存取的資源可能會無意間洩露敏感資料。

範例 1：在以下範例中，Ansible 工作將定義一個 Azure Blob 儲存容器，其中 public_access 參數設定為 container。這會允許匿名存取容器的所有 Blob 和資料。

- name: Create container test
  azure_rm_storageblob:
    resource_group: testGroup
    storage_account_name: sa001
    container: testContainer
    ...
    public_access: container
    ...

範圍過大的存取組態會將系統暴露在外，並擴大組織的受攻擊面。開放與公眾互動的服務會受到攻擊者幾乎連續的掃描和探測。

在發現並發佈針對公開服務的零時差攻擊 (例如 Heartbleed) 時問題特別大。攻擊者可主動追蹤和搜尋未修補和暴露的系統以進行攻擊。

範例 1：以下範例 Ansible 工作允許將未受限制的輸入流量傳輸至某個範圍內的連接埠，其中包括 RDP 服務連接埠 (3389)。

- name: testFWRule
azure_rm_securitygroup:
    resource_group: testRG
    name: test
    rules:
    - name: rule001
        priority: 100
        direction: Inbound
        access: Allow
        protocol: "*"
        source_port_range: "*"
        destination_port_range: "3388-3398"
        source_address_prefix: "*"
        destination_address_prefix: "*"
    - name: rule002
        priority: 100
        direction: Inbound
        access: Allow
        protocol: "*"
        source_port_range: "*"
        destination_port_range: 22
        source_address_prefix: "*"
        destination_address_prefix: "*"

執行 script 中對 GitHub Action 運算式的直接參照是動態產生的。這讓可控制輸入的任何人都可以使用 Command Injection 來侵入系統。

範例 1：以下來自 GitHub Action 的程式碼直接參照了執行 script 中的一個運算式，造成系統接受 Command Injection。

    ...
    steps:
      - run: echo "${{  github.event.pull_request.title  }}"
    ...
    

執行該動作時，shell script 會動態執行，包括執行 github.event.pull_request.title 值表示的任何程式碼。如果 github.event.pull_request.title 包含惡意可執行程式碼，則該動作將會執行惡意程式碼，從而導致 Command Injection。

SSL 標準提供在用戶端執行ＳSL 驗證檢查的原則。但這不是標準的一部分。因此，驗證邏輯將留給應用程式開發人員去實作。

研究顯示，SSL 標準規則的複雜性和開放性質有數項隱藏的危險，因此難以取得無瑕疵的自訂 SSL 實作。Android 應用程式的很大一部分是使用自訂 SSL 實作，在提供安全的通訊管道上是有缺陷的，使得應用程式容易受 man-in-the-middle 攻擊。

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 位元組的工作階段識別碼。

最成功的攻擊往往是由破解程式設計師的假設開始。如果接受 XML 文件而不驗證該文件是否符合 DTD 或 XML 架構，程式設計師等於是放任攻擊者提供非預期、不合理或惡意的輸入。當然，一個 XML 解析器不可能驗證文件的所有內容；換句話說，解析器無法了解資料的完整語意。但是，解析器可以進行完整且徹底的文件結構檢查，因此可以保證處理文件的程式碼中的內容形式是合法的。

反映型檔案下載 (Reflected File Download, RFD) 是一種可讓攻擊者製作網路釣魚 URL 或頁面的弱點，在使用者造訪該 URL 或頁面時便會啟動檔案下載，檔案中包含看似來自受信賴網域的任意內容。因為使用者信任指定的網域，所以他/她可能會開啟所下載的檔案，從而可能導致執行惡意程式碼。

攻擊者若要成功執行 RFD 攻擊，必須滿足下列要求：
- 目標應用程式反映使用者輸入而不進行適當的驗證或編碼。這用於插入承載。
- 目標應用程式允許寬鬆的 URL。攻擊者可能藉此控制所下載檔案的名稱和副檔名。
- 目標應用程式的 Content-Disposition 表頭設定錯誤，從而讓攻擊者可控制 HTTP 回應中的 Content-Type 和/或 Content-Disposition 表頭，或者目標應用程式所包含的 Content-Type 預設並非在瀏覽器中轉譯。

例如，如果應用程式使用 Spring Web MVC ContentNegotiationManager 來動態產生不同的回應格式，則滿足使 RFD 攻擊成為可能所需的條件。

ContentNegotiationManager 設定為根據要求路徑副檔名來決定回應格式，並使用 Java Activation Framework (JAF) 尋找更為符合用戶端所要求之格式的 Content-Type。它還允許用戶端透過在要求的 Accept 表頭中傳送的媒體類型來指定回應內容類型。

範例 1：在以下範例中，應用程式設定為允許路徑副檔名策略和 Java Activation Framework 來決定回應的內容類型：

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="favorPathExtension" value="true" />
  <property name="useJaf" value="true" />
</bean>

範例 2：在以下範例中，應用程式設定為允許要求的 Accept 表頭來決定回應的內容類型：

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
  <property name="ignoreAcceptHeader" value="false" />
</bean>

請注意，Spring 4.2.1 中的 ContentNegotiationManagerFactoryBean 屬性預設值如下：

- useJaf：true
- favorPathExtension：true
- ignoreAcceptHeader：falseExample 1 中所顯示的配置可讓攻擊者製作惡意 URL，如：

http://server/some/resource/endpoint/foo.bat?input=payload

以便 ContentNegotiationManager 使用 Java Activation Framework (如果在類別路徑中找到 activation.jar) 嘗試解析指定副檔名的媒體類型，並相應設定回應的 ContentType 表頭。此範例中的副檔名為「.bat」，從而產生 application/x-msdownload 的 Content-Type 表頭 (儘管確切的 Content-Type 可能依據伺服器 OS 和 JAF 組態而有所不同)。因此，一旦受害者造訪此惡意 URL，他/她的機器便會自動開始下載包含攻擊者控制內容的「.bat」檔案。如果隨後執行此檔案，受害者機器便會執行攻擊者承載所指定的任意指令。

未經驗證的 Redis 伺服器可能成為攻擊者的目標，透過危害伺服器達到涉足您內部網路的目的。

可能會針對 Redis 伺服器使用不同的攻擊方式，以對其基礎作業系統執行任意程式碼。 例如，攻擊者可以使用 Redis 指令，將 Web Shell 寫入 Web 根目錄。 用來儲存物件時，攻擊者也可能針對不同的語言 (例如 Java、Python、Ruby、PHP 等) 儲存還原序列化裝載，以便對還原序列化端點執行遠端程式碼。

請注意，即使沒有在外部暴露 Redis 伺服器，外部攻擊者仍可能透過同一網路上任意應用程式內的 Server-Side Request Forgery 弱點對其進行存取。 例如，Redis 伺服器可能成為使用 HTTP 或 Gopher 通訊協定的攻擊者。

由於 Redis 的特性，若無法從外部保護 Redis 連接埠，可能會對安全性有較大的影響。 例如，外部攻擊者會使用單一 FLUSHALL 指令來刪除整個資料集。 最近，有關於惡意攻擊網際網路上公開執行的不安全 Redis 實例的報告。 攻擊者刪除了資料庫，並要求支付贖金才會加以還原。

安全性時間戳記可指示訊息安全性資料建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送給接收者。在這些情況下，攻擊者可能誘使接收者接受惡意的訊息。

範例 1：以下 WS-SecurityPolicy 原則項目已對 <IncludeTimestamp> 標籤做出註解：

  <sp:AsymmetricBinding>
    <wsp:Policy>
      ...
      <!--<sp:IncludeTimestamp/>-->
      <sp:ProtectTokens/>
      <sp:OnlySignEntireHeadersAndBody/>
    </wsp:Policy>
  </sp:AsymmetricBinding>

安全性時間戳記可指示訊息安全性資料建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送給接收者。在這些情況下，攻擊者可能誘使接收者接受惡意的訊息。

範例 1：以下原則項目已對 <MessageAge> 標籤做出註解。

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  >
...
<!--   <wssp:MessageAge/> -->

</wsp:Policy>

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送給接收者。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送給接收者。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送該訊息。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

下列服務供應商組態要求 WebSphere 接受未簽署的進入時間戳記：

<com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi" >
...
        <securityRequestConsumerServiceConfig xmi:id="SecurityRequestConsumerServiceConfig_1211399165585">
          <addTimestamp xmi:id="AddTimestamp_1212094497592"/>
...
</com.ibm.etools.webservice.wsext:WsExtension>

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送該訊息。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

下列服務供應商組態要求 WebSphere 傳送未簽署的時間戳記：

<com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi" >
...
  <securityResponseGeneratorServiceConfig xmi:id="SecurityResponseGeneratorServiceConfig_1211568020342">
    <addTimestamp xmi:id="AddTimestamp_1211568020342"/>
...
</com.ibm.etools.webservice.wsext:WsExtension>

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送給接收者。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送給接收者。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送該訊息。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

下列用戶端組態要求 WebSphere 接受未簽署的時間戳記：

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1152150778436">
        ...
        <securityResponseConsumerServiceConfig xmi:id="SecurityResponseConsumerServiceConfig_1212093287097">
            <addTimestamp xmi:id="AddTimestamp_1212093882250"/>
            ...
</com.ibm.etools.webservice.wscext:WsClientExtension>

安全性時間戳記可指示訊息建立的時間。若攻擊者截取稍後重新傳輸的訊息，接收者可拒絕重複進行的攻擊，因為時間戳記顯示這是舊訊息。或者，時間戳記可包含一個有效期屬性，您可以使用該屬性以限制安全語義的有效時間。

若要防止攻擊者纂改時間戳記，則時間戳記必須已完成簽署。如果時間戳記並未經過簽署，攻擊者可能會在接收者未察覺的狀況下攔截 SOAP 訊息、修改時間戳記並傳送該訊息。在這些情況下，攻擊者可能會誘使接收者接受惡意的訊息。

下列用戶端組態要求 WebSphere 傳送未簽署的時間戳記：

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1152150778436">
        ...
        <securityRequestGeneratorServiceConfig xmi:id="SecurityRequestGeneratorServiceConfig_1212078169562">
          <addTimestamp xmi:id="AddTimestamp_1212093882250"/>
          ...
</com.ibm.etools.webservice.wscext:WsClientExtension>