寬鬆的存取組態會將系統暴露在外，並擴大組織的受攻擊面。開放與公眾互動的服務通常會受到惡意實體近乎連續的掃描和探測。

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

寬鬆的存取組態會將系統暴露在外，並擴大組織的受攻擊面。開放與公眾互動的服務通常會受到惡意實體近乎連續的掃描和探測。

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

寬鬆的存取組態會將系統暴露在外，並擴大組織的受攻擊面。開放與公眾互動的服務通常會受到惡意實體近乎連續的掃描和探測。

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

多數 Web 應用程式使用階段作業識別碼來識別各使用者，該識別碼通常儲存在 cookie 中，並在伺服器與網路瀏覽器間公開傳輸。


未在 cookie 中儲存階段作業識別碼的應用程式，有時會傳輸識別碼做為 HTTP 要求參數或 URL 的一部份。接受 URL 中指定的階段作業識別碼，容易讓攻擊者執行 Session Fixation 攻擊。

將階段作業識別碼置於 URL，也可能會增加 Session Hijacking 對應用程式成功攻擊的機會。當攻擊者控制受害者啟用的階段作業或階段作業識別碼時，Session Hijacking 便會發生。網路伺服器、應用程式伺服器及 Web 代理伺服器通常會儲存要求的 URL，這是種常見的作法。若 URL 中包含階段作業識別碼，也會記錄這些識別碼。增加階段作業識別碼檢視及儲存位置的數量，將增加攻擊者危及這些識別碼的機會。

HTML5 提供 localStorage 和 sessionStorage 對應，可讓開發人員維持程式值。sessionStorage 對應提供呼叫頁面的儲存空間，且持續時間為頁面實例和即時瀏覽器階段作業運算期間。但 localStorage 對應則是提供可在多個頁面實例和瀏覽器實例存取的儲存空間。此功能可讓應用程式在多個瀏覽器標籤或視窗中維持並使用相同的資訊。

舉例來說，開發人員想要在旅遊應用程式中使用多個瀏覽器標籤或實例，讓使用者可以開啟多個標籤來比較住宿方案，同時也可以保持使用者原本的搜尋條件。在傳統的 HTTP 儲存方法中，使用者進行購物時存在一定風險，且在某個標籤中所做的決定 (已儲存在階段作業或 Cookie 中) 會干擾另一個標籤中的購物操作。

使用可在多個瀏覽器標籤中利用使用者數值的功能時，開發人員必須特別謹慎，別將敏感資訊從 sessionStorage 範圍移至 localStorage (反之亦然)。

範例：以下範例將信用卡 CCV 資訊儲存在階段作業中，表示使用者已授權網站對已建檔的信用卡收取購物費用。每次要在此瀏覽器標籤頁面中購物時，都必須核准信用卡。為了避免再次輸入 CCV，該資訊會儲存在 sessionStorage 物件中。但是，開發人員也會將資訊儲存在 localStorage 物件中。

...
try {
    sessionStorage.setItem("userCCV", currentCCV);
} catch (e) {
    if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
    }
    }

    ...
    ...

    var retrieveObject = sessionStorage.getItem("userCCV");
try {
     localStorage.setItem("userCCV",retrieveObject);
} catch (e) {
     if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
	}
     ...

     var userCCV = localStorage.getItem("userCCV");
...
}
...

藉由將資訊放回 localStorage 物件中，使用者可以在其他瀏覽器標籤中和呼叫新瀏覽器時使用 CCV 資訊。這樣會略過應用程式原本工作流程的邏輯。

Dockerfile 可以為相依項和基本映像指定一個沒有界線的版本範圍。如果攻擊者能將惡意版本的相依項新增至儲存庫，或欺騙組建系統從攻擊者控制的儲存庫下載相依項，那麼如果 docker 設定為沒有特定版本的相依項時，則 docker 將以無訊息方式下載並執行遭入侵的相依項。

這種類型的弱點可能因為供應鏈攻擊而被利用，在供應鏈攻擊中，攻擊者可運用開發人員的錯誤組態，接著誤植域名，然後可將惡意套件新增至開放原始碼儲存庫。這種類型的攻擊利用對已發佈套件的信任來獲取存取權限並竊取資料。

在 docker 中，latest 標籤會自動指示未使用摘要或唯一標籤為其提供版本的映像的版本層級。Docker 會自動指派 latest 標籤做為指向最新映像資訊清單檔案的機制。由於標籤是可變的，所以攻擊者可使用 latest (或弱標籤，如imagename-lst, imagename-last, myimage) 取代映像或階層。

範例 1：以下組態指示 Docker 挑選使用最新 ubuntu 版本的基本映像。

    FROM ubuntu:Latest
    ...

Docker 不會驗證設定為支援套件管理器的儲存庫是否值得信賴。

範例 2：以下組態指示套件管理器 zypper 擷取指定套件的最新版本。

...
zypper install package
...

在 Example 2 中，如果儲存庫遭到入侵，攻擊者可能很容易便上傳符合動態標準的版本，使 zypper 下載相依項的惡意版本。

Handlebars 範本無法存取物件的原型，因為它讓應用程式容易受到 Prototype Pollution 攻擊。

當惡意使用者可以控制物件原型上的功能或屬性時，就會發生 Prototype Pollution 攻擊。控制傳遞到範本中的物件原型會導致許多漏洞，包括 Dynamic Code Evaluation、Cross-Site Scripting 和 Remote Code Execution。

範例 1：在以下設定 Handlebars 範本的範例中，依預設允許使用原型方法，以及特殊的 __defineGetter__ 函式。

let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
    allowProtoMethodsByDefault: true,
    allowedProtoMethods: {
        __defineGetter__: true
    }
}))

X-XSS-Protection 是由 Microsoft 引入的 HTTP 標頭，後來由其他瀏覽器所採用。這旨在協助阻止 Cross-Site Scripting 攻擊成功，但不慎導致弱點的情況，使得安全網站易受攻擊[1]。因此，不應在舊版 Internet Explorer 中使用此標頭，並且應透過將標頭設定為 0 將其停用。

範例 1：以下錯誤地配置了 Express 應用程式中的 Helmet 中介軟體，以針對所有版本的 Internet Explorer 啟用此標頭：

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

多數 Web 應用程式使用工作階段識別碼來識別各使用者，該識別碼通常儲存在 Cookie 中，並在伺服器與網路瀏覽器間公開傳輸。


未在 Cookie 中儲存工作階段識別碼的應用程式，有時會傳輸識別碼做為 HTTP 要求參數或 URL 的一部份。接受 URL 中指定的工作階段識別碼，容易讓攻擊者執行 Session Fixation 攻擊。

將工作階段識別碼置於 URL，也可能會增加 Session Hijacking 對應用程式成功攻擊的機會。當攻擊者控制受害者啟用的工作階段或工作階段識別碼時，Session Hijacking 便會發生。網路伺服器、應用程式伺服器及 Web 代理伺服器通常會儲存要求的 URL，這是種常見的作法。若 URL 中包含工作階段識別碼，也會記錄這些識別碼。增加工作階段識別碼檢視及儲存位置的數量，將增加攻擊者危及這些識別碼的機會。

寬鬆的存取組態會將系統暴露在外，並擴大組織的受攻擊面。開放與公眾互動的服務通常會受到惡意實體近乎連續的掃描和探測。

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

為了保持回溯相容性，Kubelet 可以在唯讀連接埠上提供其 API 的部分，而不需要驗證或授權。這些 API 的傳回值包含 Kubelet 所服務節點的非常詳細規格和效能指標，以及部署至節點之 Pod 的中繼資料。

範例 1：以下組態將 Kubelet 唯讀連接埠設定為 12345。

...
kind: KubeletConfiguration
...
readOnlyPort: 12345
...

寬鬆的存取組態會將系統暴露在外，並擴大組織的受攻擊面。開放與公眾互動的服務通常會受到惡意實體近乎連續的掃描和探測。

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

Spring 提供簡單的機制，能將任何 Spring 管理的 bean，都變成透過 RMI、HTTP、Burlap、Hessian 及 JMX 傳輸協定向外部公開的物件。從外部可以呼叫遠端 Spring bean 的任何公用方法，而且在用戶端與遠端物件之間傳遞的資料都是純文字。這些服務的主要問題在於，根據預設，它們都是開放的，而且一開始並沒有提供任何保密性或完整性的保證。

Spring 提供簡單的機制，能夠透過 Spring WS 或 XFire，將任何 Spring 管理的 bean 都變成 Web 服務。從外部可以呼叫遠端 Spring bean 的任何公用方法，而且在用戶端與 Web 服務啟用物件之間傳遞的資料都是純文字。這些服務的主要問題在於，根據預設，它們都是開放的，而且一開始並沒有提供任何保密性或完整性的保證。

Object-Graph Navigation Language (OGNL) 是一種適用於 Java 的開放原始碼運算式語言 (EL)，會允許在 Struts 2 Value Stack 內容中評估 EL 運算式。允許根據 Value Stack 來評估未驗證的運算式可能會為攻擊者提供修改系統變數或執行任意程式碼的存取權。

在以下範例中，應用程式正使用使用者所控制的未驗證資料來建立「評估 OGNL 運算式」：

OgnlContext ctx = new OgnlContext();
String expression = request.getParameter("input");
Object expr = Ognl.parseExpression(expression);
Object value = Ognl.getValue(expr, ctx, root);
System.out.println("Value: " + value);

攻擊者可能提交以下運算式以便在應用程式伺服器環境中執行任意程式碼：

(#rt = @java.lang.Runtime@getRuntime(),#rt.exec("calc.exe"))


若啟用 allow_url_fopen 選項，便可使用 HTTP 或 FTP URL 在遠端檔案上執行接受檔案名稱的 PHP 函數。該選項是在 PHP 4.0.4 中增加的，在預設情況下是開啟的，因為它可能會讓攻擊者將惡意內容引入至應用程式中。最理想的情況是，攻擊者改變遠端檔案以引入惡意的內容，因此對遠端檔案進行操作使得應用程式易受攻擊。最差的情況是，攻擊者控制執行應用程式的 URL，則他們可以將 URL 提供至遠端伺服器，將任意的惡意內容插入至應用程式。

範例 1：以下的程式碼會開啟一個檔案並讀取其內容，該檔案名稱由要求參數控制。因為 $file 的值由要求參數控制，所以攻擊者可違反程式設計師的假設，提供 URL 給遠端檔案。

<?php
$file = fopen ($_GET["file"], "r");
if (!$file) {
    // handle errors
}
while (!feof ($file)) {
    $line = fgets ($file, 1024);
    // operate on file content
}
fclose($file);
?>

若啟用 session.use_trans_sid，會使 PHP 透過 URL 傳送階段作業識別碼，這會使攻擊者更容易劫持目前的階段作業，或是欺騙使用者使用已受攻擊者控制的現有階段作業。

透過 URL 傳送的參數比 POST 參數和 cookie 值較常看見，因為它們常出現於瀏覽器歷史記錄、書籤、記錄檔以及其他高度暴露的位置中。如果攻擊者了解系統中某一作用中階段作業的秘密識別碼，則他們可能將階段作業識別碼傳回到程式中，以劫持使用者的階段作業。

除了 session hijacking 外，在 URL 上暴露階段作業識別碼也會引發 session fixation 攻擊。在一般情況下，攻擊者會利用 Session Fixation 弱點，在 Web 應用程式中建立一個新的階段作業，並記錄關聯的階段作業識別碼。接著，攻擊者會讓受害者使用該階段作業識別碼驗證伺服器，這樣一來，會讓攻擊者透過使用中的階段作業取得存取使用者帳戶的權限。透過 URL 傳送階段作業識別碼可能會讓攻擊者攻擊大批的受害者，這種攻擊方式是藉由將受危害的階段作業識別碼的 URL 透過電子郵件發送給受害者，或另一種大規模的通訊機制來執行。

Android 活動分配未在 onPause()、onStop()，或 onDestroy() 收回 (callback) 中解除的媒體物件。在必須將目前活動傳送至背景時，或由於系統資源過低而必須暫時破壞活動時，Android OS 會啟用這些收回 (callback)。由於未能適當地解除媒體物件，該活動會造成後續 (其他應用程式甚至相同應用程式) 對於 Android 媒體硬體的存取容錯回復至軟體實作，甚至完全失敗。若有過多未解除的媒體實例保持在開啟狀態，可能會導致 Android 異常，進而造成 Denial of Service。而且，若在活動暫停時仍持有實例，會因為不必要的耗電而對使用者經驗造成負面影響。

範例：下列程式碼描述不會取代基本 onPause() 方法的 Android 活動，該方法應該用於解除物件，且該活動不會在其關機順序期間正確地解除該方法。

public class UnreleasedMediaActivity extends Activity {
  private MediaPlayer mp;

  @Override
  public void onCreate(Bundle state) {
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      mp.stop();
  }
}

程式可能會無法釋出檔案控制碼。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：下列方法絕對不會關閉它所開啟的檔案控制碼。用於 ZipFile 的 finalize() 方法最終會呼叫 close()，但是並不保證在叫用 finalize() 方法前會經過多少時間。因此，在繁忙的環境中，這可能會導致 JVM 用盡它所有的檔案控制碼。

public void printZipContents(String fName) throws ZipException, IOException, SecurityException, IllegalStateException, NoSuchElementException {
  ZipFile zf = new ZipFile(fName);
  Enumeration<ZipEntry> e = zf.entries();

  while (e.hasMoreElements()) {
    printFileInfo(e.nextElement());
  }
}

範例 2：在正常條件下，以下修正會在列印出所有 zip 檔項目之後，適當地關閉檔案控制碼。但是，如果在重複透過項目時發生異常，zip 檔案控制碼就不會關閉。如果經常發生此狀況，JVM 仍然可能會耗盡所有可用的檔案控制碼。

public void printZipContents(String fName) throws ZipException, IOException, SecurityException, IllegalStateException, NoSuchElementException {
  ZipFile zf = new ZipFile(fName);
  Enumeration<ZipEntry> e = zf.entries();

  while (e.hasMoreElements()) {
    printFileInfo(e.nextElement());
  }
  zf.close();
}

程式可能會無法釋出通訊端。


資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：下列方法絕對不會關閉它所開啟的通訊端。因此，在繁忙的環境中，這可能會導致 JVM 用盡它所有的通訊端。

private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
  Socket sock = new Socket(host, port);
  BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));

  while ((String socketData = reader.readLine()) != null) {
    System.out.println(socketData);
  }
}

範例 2：在正常條件下，以下修正會適當地關閉通訊端以及任何相關的串流。但是，如果對螢幕讀取或寫入資料時發生異常，通訊端物件就不會關閉。如果經常發生此狀況，系統就會耗盡所有通訊端，並且無法處理任何其他連線。

private void echoSocket(String host, int port) throws UnknownHostException, SocketException, IOException
{
  Socket sock = new Socket(host, port);
  BufferedReader reader = new BufferedReader(new InputStreamReader(sock.getInputStream()));

  while ((String socketData = reader.readLine()) != null) {
    System.out.println(socketData);
  }
  sock.close();
}