多數 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 (反之亦然)。

範例 1：以下範例將信用卡 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 資訊。這樣會略過應用程式原本工作流程的邏輯。

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。而且，若在活動暫停時仍持有實例，會因為不必要的耗電而對使用者經驗造成負面影響。

範例 1：下列程式碼描述不會覆寫基本 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();
}

依照預設，Java Applet 可開啟資料庫通往 Applet 下載來源伺服器的連線。在受信任的環境中，這項行為是受到認可的，不過在不可信賴的環境中，攻擊者可能會使用該 Applet 來獲取資料庫憑證，最後便能直接進入資料庫。
範例 1：下列程式碼顯示 Hardcoded Database Password 如何在 Applet 中進行使用。

public class CustomerServiceApplet extends JApplet
{
    public void paint(Graphics g)
    {
        ...
        conn = DriverManager.getConnection ("jdbc:mysql://db.example.com/customerDB", "csr", "p4ssw0rd");
        ...

由於 Applet 程式碼下載到用戶端，因此具有強制編碼 JDBC 憑證的 Applet 使用者可輕易發現憑證。此外，若透過未加密的通道進行資料庫連線，則任何能夠攔截網路流量的使用者也可取得憑證。最後，若允許使用者直接連線到資料庫，可公開存取的資料庫伺服器將顯露無遺，這樣一來，攻擊者便會把該資料庫做為直接網路攻擊的目標。

如果結構不進行強制嚴格的輸入驗證，則允許對任意元素或屬性進行驗證。這樣就讓攻擊者得以將惡意文件送到系統中。

範例 1：假設您正使用下列兩種結構進行驗證。

結構 1：

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"  >
  <xs:element name="cart" >
    <xs:complexType>
      <xs:sequence>
	<xs:element name="itemID" maxOccurs="1" />
	<xs:any namespace="http://itemInfo" processContents="lax" minOccurs="1" maxOccurs="5"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

結構 2：

<?xml version="1.0"?>
<xsd:schema targetNamespace="http://itemInfo" xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
  <xsd:element name="name" type="xsd:string"/>
  <xsd:element name="description" type="xsd:string"/>
</xsd:schema>

結構 1 允許 http://itemInfo 命名空間中的任意標籤接受驗證，因此允許下列 XML 通過驗證。

<?xml version=\"1.0\" ?>
<cart xmlns:itemInfo="http://itemInfo">
  <itemID>123</itemID>
  <itemInfo:name>Shoes</itemInfo:name>
  <itemInfo:description>Black Shoes</itemInfo:description>
  <itemInfo:price>1.00</itemInfo:price>
</cart>

上述 XML 包含一個結構 2 中未定義的 itemInfo:price 標籤。因此，有可能誘騙此 XML 文件的使用者將 Shoes 的價格設定為 $1。

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

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

如果此金鑰遭到入侵，則為您的 AWS 根使用者帳戶定義存取金鑰會使您的所有 AWS 資源面臨風險。

範例 1：以下範例範本為 root 使用者帳戶建立存取金鑰。

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "SecKeys": {
            "Type": "AWS::IAM::AccessKey",
            "Properties": {
            "UserName": "Root"
            }
        }
    }
}

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

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