函數若可覆寫在目前範圍中初始化的變數，則也會讓攻擊者得以影響依賴已覆寫變數的程式碼執行。
範例 1：若攻擊者在以下 PHP 程式碼區段中為 str 提供惡意值，則呼叫 parse_str() 時可能會在目前範圍中覆寫包括 first 在內的任意變數。在此案例中，若包含 JavaScript 的惡意值覆寫 first，此程式會容易受到 Cross-Site Scripting 攻擊。

<?php
    $first="User";
    ...
    $str =  $_SERVER['QUERY_STRING'];
    parse_str($str);
    echo $first;
?>

函數若可覆寫已初始化的全域變數，則也會讓攻擊者得以影響依賴已覆寫變數的程式碼執行。
範例 1：若攻擊者在以下 PHP 程式碼區段中為 str 提供惡意值，則呼叫 mb_parse_str() 時可能會覆寫包括 first 在內的任意變數。在此案例中，若包含 JavaScript 的惡意值覆寫 first，此程式會容易受到 Cross-Site Scripting 攻擊。

<?php
    $first="User";
    ...
    $str =  $_SERVER['QUERY_STRING'];
    mb_parse_str($str);
    echo $first;
?>

Session Fixation 弱點會在以下情況中出現：

1.Web 應用程式驗證一個使用者時，事先沒有使現有階段作業失效，而繼續使用已經與使用者相關聯的階段作業。
2.攻擊者可奪取使用者的階段作業識別碼，所以，在使用者驗證之後，攻擊者就可以存取驗證的階段作業。

在一般情況下，攻擊者會利用 Session Fixation 弱點，在 Web 應用程式中建立一個新的階段作業，並記錄關聯的階段作業識別碼。接著，攻擊者會讓受害者使用該階段作業識別碼驗證伺服器，這樣一來，會讓攻擊者透過作用中的階段作業取得存取使用者帳戶的權限。

有些架構 (例如 Spring Security) 在建立新的階段作業時，會自動使現有階段作業無效。若不採取此行為，應用程式會容易遭受此類攻擊。

範例 1：以下範例顯示受 Spring Security 保護之應用程式的片段，其中 Session Fixation 保護已停用。

	<http auto-config="true">
        ...
        <session-management session-fixation-protection="none"/>
	</http>

即使是易受攻擊的應用程式，此處說明的特定攻擊是否會成功取決於數個受攻擊者青睞的因素：存取未受監視的公用終端機、讓已受攻擊的網路連線保持繼續運作的能力、被吸引登入公用終端機上易受攻擊應用程式的受害者。在大多數情況下，只要肯花時間，前面兩個因素是可以克服的。只要網站有趣，不難找到使用公用終端機、也有興趣登入到易受攻擊的應用程式的受害者。網站越不受歡迎，那麼使用這個公用終端機的人就會越少，這樣一來，前述攻擊成功的可能性也越低。

攻擊者攻擊 Session Fixation 弱點所面臨的最大挑戰是：誘導受害者使用攻擊者已知的階段作業識別碼來驗證易受攻擊的應用程式。在 Example 1 中，攻擊者使用直接明顯的方法並不高明，對於攻擊知名度較低的網站並不適用。但是，千萬不要過於大意，攻擊者有許多手段來突破上述攻擊的限制。攻擊者最常採用的技術包括：利用目標網站中的 Cross-Site Scripting 或 HTTP Response Splitting 弱點 [1]。透過誘使受害者向一個易受攻擊的應用程式提交惡意要求，讓應用程式將 JavaScript 或者其他程式碼反映到受害者的瀏覽器，這樣一來，攻擊者就可以建立 Cookie，使受害者重新使用受攻擊者控制的階段作業識別碼。

要特別注意的是，通常 Cookie 會與某個已知 URL 相關聯的上層網域繫結在一起。如果多個應用程式位於同一個上層網域 (例如 bank.example.com 和 recipes.example.com)，其中一個應用程式存在弱點，那麼攻擊者便可以透過此弱點設定一個 Cookie，並在其中包含已修改的階段作業識別碼，且該階段作業識別碼可以在 example.com [2] 網域上的所有應用程式中交互使用。

其他攻擊方向還包括 DNS Poisoning 和其他以網路為基礎的攻擊，攻擊者會透過重新指向對有效網站的要求，誘使攻擊者存取惡意網站。一般來說，以網路為基礎的攻擊包括：實際出現在受害者的網路上，或是控制網路上已受攻擊的機器。雖然透過遠端方式發動攻擊比較困難，但是這類攻擊不容忽視。安全性較差的階段作業管理機制 (例如在 Apache Tomcat 中的預設實作)，可以將通常儲存在 Cookie 中的階段作業識別碼也指定給 URL。這可讓攻擊者只要透過電子郵件發送惡意 URL，就可以誘使受害者使用修改過的階段作業識別碼。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此方法呼叫永遠都不會失敗」以及「即使此呼叫失敗也沒有關係」。因此當程式設計師忽略異常時，已暗示他們是以其中一個假設來執行操作。

範例 1：以下所引用的程式碼忽略了由 doExchange() 拋出的罕見異常。

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

如果拋出了 RareException，程式會繼續執行，就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況，這將使得事後嘗試尋找程式此異常的運作方式變得很困難。

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

範例 1：以下範例顯示設定了 1 小時 authentication 逾時時間的 ASP.NET MVC。

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

如果逾時時間屬性尚未指定，則預設的 authentication 逾時時間為 30 分鐘。

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

範例 1：以下範例顯示使用 low 階段作業安全性配置的 CakePHP。

    Configure::write('Security.level', 'low');

與 Session.timeout 設定配合使用，Security.level 設定可定義階段作業的有效時間。實際階段作業逾時時間等於 Session.timeout 乘以下列其中一項倍數：

'high' = x 10
'medium' = x 100
'low' = x 300

當網站必須能夠為使用者提供下載時，開啟這些下載的選項意味著在瀏覽器中執行的任何已提供檔案都可以在與該網站相同的安全環境中，於目前瀏覽器中開啟。
如果攻擊者能夠操縱下載的檔案，便可插入在瀏覽器中執行的 HTML 或指令碼來充當 Cross-site scripting 攻擊，從而竊取或操縱目前階段作業中的資訊。

範例 1：以下範例明確停用了針對在瀏覽器中執行的已提供下載的防護。

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

app.use(helmet({
    ieNoOpen: false
}));
...

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

範例 1：以下範例中的程式碼為未活動時間間隔上限設定了負值，導致階段作業無限期地處於作用中狀態。

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

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

範例 1：如果工作階段逾時時間為零或小於零，該工作階段永遠不會過期。以下範例顯示工作階段逾時時間設定為 -1，就會無限期保留工作階段為作用中。

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

<session-timeout> 標籤定義 Web 應用程式中，所有工作階段的預設逾時時間間隔。如果沒有 <session-timeout> 標籤，就會交由容器來設定預設逾時時間。

當程式呼叫權限函數 (比如 chroot()) 時，它必須先取得 root 權限。當權限操作完成後，程式應該馬上丟棄 root 權限並且回傳呼叫它的使用者權限等級。
範例：以下程式碼會呼叫 chroot() 將應用程式限制到 APP_HOME 下的檔案系統子集，這是為了防止攻擊者使用程式對位於別處的檔案進行未經授權的存取。然後程式碼就會開啟使用者指定的檔案並處理檔案目錄。

...
chroot(APP_HOME);
chdir("/");

FILE* data = fopen(argv[1], "r+");
...

在打開任何檔案之前，把應用程式的權限限制在 home 目錄內是相當安全的方法。然而，缺少使用一些非零值對函數 setuid() 的呼叫，意味著應用程式仍然繼續在使用沒有必要的 root 權限進行操作。只要攻擊者成功利用應用程式，就會引發權限提升攻擊，因為所有的惡意操作都將以超級使用者的權限來執行。如果應用程式把權限等級降低為非 root 使用者，那麼潛在的破壞立即會下降許多。

開發作業一般會為了除錯或測試目而增加一些「後門」程式碼，這些程式碼不會隨應用程式一起提供或部署。 當這類除錯程式碼意外地留在應用程式中時，會導致應用程式開放在未預期的互動模式。 這些後門入口點很容易造成安全問題，因為在設計或者測試期間，並沒有將它們考慮在內，並且不會出現在應用程式設計中的操作環境中。

chroot() 系統呼叫允許程式修改其 File System 的根目錄含義。在適當地進行 chroot() 呼叫之後，程式無法存取新根目錄所定義的目錄樹狀架構之外的任何檔案。這樣的環境叫作 chroot jail，通常是用來阻止程式被推翻、並用來存取未經授權檔案的可能性。例如，很多 FTP 伺服器在 chroot jail 環境中執行，以便用來防止發現新伺服器弱點的攻擊者有能力下載密碼檔或者其他系統中的敏感檔案。

不適當的使用 chroot() 可能會讓攻擊者避開 chroot jail。因為 chroot() 函數呼叫不會改變程式目前的工作目錄，所以在呼叫 chroot() 之後，相關路徑仍然會參照 chroot jail 之外的 File System 資源。

範例 1：考慮以下來自 (假設的) FTP 伺服器的來源程式碼：

chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
  fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);

這段程式碼負責從網路中讀取一個檔案名稱、在本機端開啟對應的檔案，並將資訊內容傳送到網路上。這段程式碼可以用來執行 FTP 指令 GET。FTP 伺服器在其初始化程式中呼叫 chroot()，以避免存取 /var/ftproot 以外的檔案。但是，因為伺服器沒能藉由呼叫 chdir("/") 來變更目前的工作目錄，所以攻擊者就能要求檔案 "../../../../../etc/passwd"，並取得系統密碼檔案的副本。

未能封鎖不需要的網路流量，將會擴大雲端服務的受攻擊面。開放與公眾互動的服務會受到惡意實體幾乎連續的掃描和探測。

依預設，Terraform 會部署只接受來自私有 IP 位址連線的 Google Cloud SQL Database 執行個體。選用的 Authorized Networks 設定定義了可接受的公用 IP 位址範圍。

範例 1：以下 Terraform 組態在 authorized_networks 區塊中將 value 設為 0.0.0.0/0。/0 的 CIDR 區塊會接受來自 0.0.0.0 和 255.255.255.255 之間任何 IP 位址的連線。

resource "google_sql_database_instance" "db-demo" {
  ...
  settings {
  ...
    ip_configuration {
    ...
      authorized_networks {
        name  = "any ip"
        value = "0.0.0.0/0"
      }
    ...
    }
    ...
  }
  ...
}

未能封鎖不需要的網路流量，將會擴大雲端服務的受攻擊面。開放與公眾互動的服務會受到惡意實體幾乎連續的掃描和探測。

依預設，Compute Engine 執行個體的序列連接埠無法進行主控台存取。若啟用序列主控台存取，可能容許攻擊者從任何 IP 位址連線到 Compute Engine 執行個體，因為序列連接埠不支援以 IP 為基礎的存取限制。

範例 1：以下 Terraform 組態透過在 metadata 引數中將 serial-port-enable 設為 true，來允許互動式序列主控台存取。

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    serial-port-enable = true
    ...
  }
  ...
}

未能封鎖不需要的網路流量，將會擴大雲端服務的受攻擊面。開放與公眾互動的服務會受到惡意實體幾乎連續的掃描和探測。

私有 GKE 節點沒有外部 IP 位址。在這些節點上執行的 Pod 無法在叢集邊界之外進行通訊。停用公用端點可透過將其管理限制為內部私有 IP 位址來保護 GKE 叢集。如未能強制執行私有端點和私有節點，會將叢集暴露給公眾。

範例 1：以下 Terraform 組態允許任何公用 IP 位址存取叢集節點和控制層，因為 enable_private_nodes 和 enable_private_endpoint 已設為 false。

resource "google_container_cluster" "cluster-demo" {
...
  private_cluster_config {
    enable_private_endpoint = false
    enable_private_nodes = false
  }
...
}

開發作業一般會為了除錯或測試目而增加一些「後門」程式碼，這些程式碼不會隨應用程式一起提供或部署。當這類除錯程式碼意外地留在應用程式中時，會導致應用程式開放在未預期的互動模式。這些後門入口點很容易造成安全問題，因為在設計或者測試期間，並沒有將它們考慮在內，並且不會出現在應用程式設計中的操作環境中。

開發作業一般會為了除錯或測試目而增加一些「後門」程式碼，這些程式碼不會隨應用程式一起提供或部署。當這類除錯程式碼意外地留在應用程式中時，會導致應用程式開放在未預期的互動模式。這些後門入口點很容易造成安全問題，因為在設計或者測試期間，並沒有將它們考慮在內，並且不會出現在應用程式設計中的操作環境中。

遭遺忘的除錯程式碼中最常見的示例，是出現在 Web 應用程式中的 main() 方法。雖然這在軟體產品的開發過程中是完全可接受的，但是屬於 J2EE 應用程式那部分的類別不應該定義 main()。

不同的作業系統會使用不同的字元來做為檔案分隔符號。例如，Microsoft Windows 系統使用的是「\」，而 UNIX 系統則使用「/」。若要在不同的平台上執行應用程式，則 Hardcoded 檔案分隔符號會導致應用程式邏輯的執行不正確，與可能的 Denial of Service。

範例 1：以下程式碼使用 Hardcoded 檔案分隔符號來開啟檔案：

...
File file = new File(directoryName + "\\" + fileName);
...

HttpRequest 類別以陣列存取形式 (例如 Request["myParam"]) 提供對 QueryString、Form、Cookies 或 ServerVariables 集合中變數的程式化存取。存在多個名稱相同的變數時，.NET Framework 會傳回在集合中以下列順序搜尋時第一個出現的變數值：QueryString、Form、Cookies，然後 ServerVariables。因為 QueryString 依搜尋順序第一個出現，因此 QueryString 參數可以取代表單、Cookie 及伺服器變數的值。同樣地，表單值可以取代 Cookies 和 ServerVariables 集合中的變數，而 Cookies 集合的變數可取代 ServerVariables 的變數。
範例 1：想像一個金融應用程式暫時在 Cookie 中儲存使用者的電子郵件地址，並當要聯絡使用者時讀取此值。以下程式碼讀取 Cookie 值並將帳戶餘額傳送到指定的電子郵件地址。

...
    String toAddress = Request["email"];        //Expects cookie value
    Double balance = GetBalance(userID);
    SendAccountBalance(toAddress, balance);
...

假設在造訪 http://www.example.com/GetBalance.aspx 時執行 Example 1 中的程式碼。若攻擊者能夠使通過驗證的使用者按下要求 http://www.example.com/GetBalance.aspx?email=evil%40evil.com 的連結，則含有使用者帳戶餘額的電子郵件將會送往 evil@evil.com。

HttpRequest 類別以陣列存取形式 (例如 Request["myParam"]) 提供對 QueryString、Form、Cookies 或 ServerVariables 集合中變數的程式化存取。存在多個名稱相同的變數時，.NET Framework 會傳回在集合中以下列順序搜尋時第一個出現的變數值：QueryString、Form、Cookies，然後 ServerVariables。因為 QueryString 依搜尋順序第一個出現，因此 QueryString 參數可以取代表單、Cookie 及伺服器變數的值。同樣地，表單值可以取代 Cookies 和 ServerVariables 集合中的變數，而 Cookies 集合的變數可取代 ServerVariables 的變數。
範例 1：以下程式碼檢查 HTTP Referer 表頭伺服器變數，以確認要求在提供內容前是否來自於 www.example.com。

    ...
    if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
        ServeContent();
    else
        Response.Redirect("http://www.example.com/");
    ...

假設在造訪 http://www.example.com/ProtectedImages.aspx 時執行 Example 1 中的程式碼。若攻擊者對 URL 做一個直接的要求，則不會設定適當的 Referer 表頭，而要求將失敗。不過，若攻擊者以必要值提交偽造 HTTP_REFERER 參數 (如 http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com)，則查詢將從 QueryString 傳回值，而不是 ServerVariables，同時檢查也將成功。