當遇到下列狀況時會發生檔案權限操作錯誤：

1.攻擊者能夠指定在檔案系統上修改權限的作業中所使用的路徑。

2.攻擊者能夠指定檔案系統上的作業所指派的權限。

範例 1：以下程式碼使用來自系統屬性的輸入，設定預設權限遮罩。如果攻擊者能夠修改系統屬性，就能使用程式取得程式所操縱檔案的存取權。如果程式也存在 Path Manipulation 弱點，則攻擊者可能會使用這個弱點存取系統上的任意檔案。

  String permissionMask = System.getProperty("defaultFileMask");
  Path filePath = userFile.toPath();
  ...
  Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
  Files.setPosixFilePermissions(filePath, perms);
...

依預設，Flash 應用程式需遵守相同來源策略 (Same Origin Policy)，它可以確保只有在兩個 SWF 應用程式都來自相同網域時，才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。但是，變更設定時應特別小心，因為過度允許的跨網域策略會允許惡意應用程式以不適當的方式與受害者應用程式通訊，導致欺騙、資料遭竊取、傳遞和其他攻擊。

範例 1：以下內容是使用萬用字元在程式上指定允許應用程式與哪些網域通訊的範例。

   flash.system.Security.allowDomain("*");

使用 * 做為給 allowDomain() 的引數，表示應用程式的資料可以讓其他來自任何網域的 SWF 應用程式存取。

依預設，Flash 應用程式需遵守相同來源策略 (Same Origin Policy)，它可以確保只有在兩個 SWF 應用程式都來自相同網域時，才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。從 Flash Player 9,0,124,0 開始，Adobe 也引進了定義 Flash Player 可以在網域間傳送哪些自訂表頭的功能。但是，定義這些設定時應特別小心，因為將過度允許的自訂表頭策略和過度允許的跨網域策略一起套用時，會允許惡意應用程式將其選擇的表頭傳送到目標應用程式，可能會導致多種攻擊，或在不知道如何處理所接收之表頭的應用程式執行中造成錯誤。

範例 1：以下配置顯示了使用萬用字元指定 Flash Player 可以在網域間傳送哪些標頭。

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

使用 * 做為 headers 屬性的值，表示任何表頭都會在網域間傳送。

依預設，Flash 應用程式需遵守相同來源策略 (Same Origin Policy)，它可以確保只有在兩個 SWF 應用程式都來自相同網域時，才可以存取彼此的資料。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改策略。但是，決定誰可以影響設定時應特別小心，因為過度允許的跨網域策略會允許惡意應用程式以不適當的方式與受害者應用程式通訊，導致欺騙、資料遭竊取、傳遞和其他攻擊。Policy restrictions bypass 弱點會在以下情況中出現：

1. 資料從不可信賴的來源進入應用程式。

2. 資料用來載入或修改跨網域策略設定。
範例 1：以下程式碼對載入的 SWF 檔案使用其中一個參數的值，做為載入跨網域策略檔案的來源 URL。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

範例 2：以下程式碼對載入的 SWF 檔案使用其中一個參數的值，以定義可信任網域的清單。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

從 Flash Player 7 開始，透過 HTTP 載入的 SWF 應用程式不允許存取預設透過 HTTPS 載入的 SWF 應用程式。Adobe Flash 允許開發人員在程式上或透過 crossdomain.xml 組態設定檔案的適當設定來修改此限制。但是，定義這些設定時應特別小心，因為 HTTP 載入的 SWF 應用程式容易遭到 man-in-the-middle 攻擊，因此不應該受信賴。

範例：以下程式碼會呼叫 allowInsecureDomain()，它會關閉以下限制：防止 HTTP 載入的 SWF 應用程式存取 HTTPS 載入之 SWF 應用程式的資料。

   flash.system.Security.allowInsecureDomain("*");

在以下情況會發生 Hadoop 叢集控制錯誤：

- 資料從一個不可信賴的來源進入程式。

- 資料被 Hadoop 叢集的核心元件例如 NameNode、DataNode、JobTraker 用來更改叢集的狀態。

Hadoop 叢集是不友善的環境。當未正確設定安全配置，無法防護未獲授權而存取叢集節點時，攻擊就有可能控制基礎架構。這可能造成 Hadoop 叢集提供的資料被竄改。

範例 1： 下列程式碼顯示一般用戶端應用程式中的 Job 提交，從 Hadoop 叢集主機器的指令行取其輸入資料：

  public static void run(String args[]) throws IOException {

    String path = "/path/to/a/file";
    DFSclient client = new DFSClient(arg[1], new Configuration());
    ClientProtocol nNode = client.getNameNode();

    /* This sets the ownership of a file pointed by the path to a user identified
     * by command line arguments.
     */
    nNode.setOwner(path, args[2], args[3]);
    ...
  }

包含另外一個網站中可執行的內容是有風險的。這樣會導致您網站的安全性與另一個網站息息相關。

範例： 請思考以下 script 標籤。

  <script src="http://www.example.com/js/fancyWidget.js"></script>

如果這個標籤出現在 www.example.com 以外的網站上，則該網站依賴 www.example.com 提供正確且無惡意的程式碼。如果攻擊者能危害 www.example.com，他們就能修改 fancyWidget.js 的內容來破壞網站的安全性。例如，他們可以新增程式碼至 fancyWidget.js 來竊取使用者的機密資料。

當敏感資料 (如密碼或密鑰) 沒有從記憶體中刪除而被駭客看到的時候，就會產生 Heap Inspection 弱點。

realloc() 函數通常是用來提高分配記憶體區塊的大小。此操作通常需要將舊記憶體區塊中的內容轉移到容量更大的新記憶體區塊。它會完整無缺地保留原來記憶體區塊中的內容，但是不會讓程式得到任何內容，藉此阻止了程式清除記憶體中敏感資訊的能力。如果攻擊者之後能夠檢查記憶體傾印的內容，敏感資料就會暴露出來。

範例：以下程式碼在包含敏感資料的緩衝區中呼叫了 realloc()：

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

這嘗試清除記憶體中的敏感資料，但因為使用了 realloc()，所以資料副本仍然會在原來對 plaintext_buffer 分配的記憶體中暴露出來。

當敏感資料 (如密碼或密鑰) 沒有從記憶體中刪除而被駭客看到的時候，就會產生 Heap Inspection 弱點。

VirtualLock 函數是用來鎖住記憶體的頁面，以防止在磁碟中被分頁。然而，在 Windows 95/98/ME 作業系統裡，這個函數是不能完整執行的，而且沒有任何影響。

程式設計師通常會信任隱藏欄位的內容，預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改，或以攻擊資料取代這些內容。

範例：

  Hidden hidden = new Hidden(element);

若隱藏欄位具有敏感資訊，該資訊的快取方式將與其他的頁面相同。這可能會導致敏感資訊在使用者不知情的狀況下貯存至瀏覽器快取中。

在現代瀏覽器中，通常預設啟用 X-XSS-Protection 標頭。設定標頭值為 false (0) 時，會停用 Cross-Site Scripting 保護。

可在多個位置設定標頭，並應檢查該標頭是否存在配置錯誤與惡意篡改。

範例：以下程式碼會將受 Spring Security 保護的應用程式設定為停用 XSS 保護：

	<http auto-config="true">
        ...
        <headers>
            ...
            <xss-protection xss-protection-enabled="false" />
        </headers>
	</http>

HTML5 的功能之一便是在用戶端 SQL 資料庫儲存資料的能力。開始從資料庫寫入和讀取時，最重要的資訊就是其名稱。因此，各使用者的資料庫名稱必須為唯一字串。如果資料庫名稱很容易猜中，那麼未授權的對象 (如其他使用者) 便可能偷取敏感資料或毀損資料庫項目。
範例：下列程式碼使用了易於猜中的資料庫名稱：

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

此程式碼將成功執行，但能夠猜到資料庫名稱為 'mydb' 的人都可以加以存取。

HTML5 提供了簡易輸入表單欄位驗證的新功能。您可以藉由 required 屬性指定輸入表單欄位是否為必要。指定表單類型可確保輸入內容會根據其類型進行檢驗。您甚至可以提供自訂 pattern 屬性，根據一般表示式檢查輸入內容。但是，若在表單標籤上新增 novalidate，並在提交輸入標籤上新增 formnovalidate 屬性，則此驗證便會停用。

範例 1： 下列範例藉由 novalidate 屬性停用表單驗證。

      <form action="demo_form.asp" novalidate="novalidate">
        E-mail: <input type="email" name="user_email" />
        <input type="submit" />
      </form>

範例 2： 下列範例藉由 formnovalidate 屬性停用表單驗證。

      <form action="demo_form.asp" >
        E-mail: <input type="email" name="user_email" />
        <input type="submit" formnovalidate="formnovalidate"/>
      </form>

停用驗證的 HTML 表單對使用者而言並不方便，且可能造成伺服器面臨各種類型的攻擊。未經驗證的輸入是導致各種弱點的根源，如 cross-site scripting、process control 和 SQL injection。

由於 Spectre 和 Meltdown 等弱點導致側通道攻擊的存在，因此強制執行指定 Web 文件的資料隱私變得非常重要。Cross-Origin Opener Policy (COOP) 的建立就是為了幫助防止因側通道攻擊而導致敏感資訊暴露。具體來說，COOP 可以強制執行文件瀏覽情境群組與其他外部文件 (例如彈出視窗) 的隔離。

範例 1：以下程式碼顯示 Django 架構中不安全的 COOP 設定 'unsafe-none'。由於側通道攻擊，這可能會允許外部文件存取來源文件的瀏覽情境群組的私有資料。

SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'

MIME 攔截是檢查位元組串流內容的做法，可推算其中所包含資料的檔案格式。

如果未明確停用 MIME 攔截，攻擊者可以操縱某些瀏覽器以非預期的方式解譯資料，進行導致出現 Cross-Site Scripting 攻擊。對於可能包含使用者可控內容的每個頁面，您應該使用 HTTP 標頭 X-Content-Type-Options: nosniff。

範例：以下程式碼會將受 Spring Security 保護的應用程式設定為停用 MIME 攔截保護：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指示在網頁瀏覽器中轉譯時，允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。但設定不當的標頭無法提供這種額外一層的安全性。該原則藉助於 15 個指令進行定義，其中包括 8 個用於控制資源存取的指令，即：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。

每個指令都使用來源清單做為一個值，此值指定針對該指令所涵蓋的功能，網站可存取的網域。開發人員可使用萬用字元 * 來指示所有或部分來源。所有指令都不是強制性的。瀏覽器將允許未列示指令的所有來源，或從選用的 default-src 指令衍生值。此外，此表頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中，其實做為 X-Content-Security-Policy，而在第 25 版之前的 Chrome 中，其實做為 X-Webkit-CSP。兩個名稱都已棄用，取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱，以及對待多次出現之同一表頭和單一表頭中重複指令的方式，開發人員很可能會錯誤地配置此表頭。

考慮以下配置錯誤的情況：

- 具有 unsafe-inline 或 unsafe-eval 的指令違背了 CSP 的目的。
- 已設定 script-src 指令，但未配置任何 Script nonce。
- 已設定 frame-src，但未配置任何 sandbox。
- 在同一回應中允許使用此表頭的多個實例。開發團隊和安全性團隊可能都會設定表頭，但其中一個可能會使用棄用的名稱之一。雖然在不存在具有最新名稱 (即，內容安全性原則) 的表頭時會接受棄用的表頭，但如果存在具有 content-security-header 名稱的原則，便會忽略棄用的表頭。舊版本只理解棄用的名稱，因此，要實現預期支援，回應必須包含具有這三個名稱的相同原則。
- 如果在表頭的同一實例中重複出現某個指令，則會忽略之後出現的所有該指令。

範例 1：以下 django-csp 配置使用不安全的指令 unsafe-inline 和 unsafe-eval，以便允許內嵌 Script 和程式碼評估：

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指示在網頁瀏覽器中轉譯時，允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。

依預設，Spring Security 和其他架構並不新增內容安全性原則標頭。Web 應用程式作者必須宣告一或多個安全性原則，以強制執行或監視受保護的資源，進而從這額外一層的安全性受益。

允許將您的網站新增到框架會引起安全問題。例如，這可能導致點擊劫持弱點，或允許不希望的跨框架通訊。

依預設，Spring Security 之類的架構包含 X-Frame-Options 標頭，以指示瀏覽器是否應對應用程式進行框架處理。停用或未設定此標頭會導致跨框架相關弱點。

範例 1：以下程式碼會將受 Spring Security 保護的應用程式設定為停用 X-Frame-Options 標頭：

	<http auto-config="true">
        ...
        <headers>
            ...
            <frame-options disabled="true"/>
        </headers>
	</http>

內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指定瀏覽器中允許的安全性相關行為，包括可從中擷取內容的位置允許清單。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。但設定不當的標頭無法提供這種額外一層的安全性。該原則藉助於 15 個指令進行定義，其中包括 8 個用於控制資源存取的指令，即：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。這 8 個指令都將一個來源清單做為值，指定網站可存取的網域，以使用該指令所涵蓋的功能。開發人員可使用萬用字元 * 來指示所有或部分來源。其他來源清單關鍵字 (例如 'unsafe-inline' 和 'unsafe-eval') 提供更精細的方式來控制 script 執行，但這些是潛在有害的關鍵字。所有指令都不是強制性的。瀏覽器允許未列示指令的所有來源，或從選用的 default-src 指令衍生值。此外，此標頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中，其實作為 X-Content-Security-Policy，而在第 25 版之前的 Chrome 中，則實作為 X-Webkit-CSP。兩個名稱都已棄用，取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱，以及對待多次出現之同一標頭和單一標頭中重複指令的方式，開發人員很可能會錯誤地設定此標頭。

範例 1：以下程式碼會設定過度寬鬆且不安全的 default-src 指令：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

在 HTML5 之前，網頁瀏覽器會強制執行相同來源原則，確保在使用 JavaScript 存取網頁內容時，JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意的網站可使用用戶端的憑證來執行 JavaScript，從其他網站載入敏感的資訊，從中挑選出資訊並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。

範例 1：以下是使用萬用字元在程式上指定允許應用程式與哪些網域通訊的範例。

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

使用 * 做為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。