Cookie Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給網頁使用者。

與許多軟體的安全性弱點一樣，Cookie manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭，Cookie manipulation 攻擊還會導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說，如果您嘗試使用禁用的字元設定表頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並且將該名稱設定在 HTTP 回應的 Cookie 表頭中。

...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 cookie 的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己傳遞惡意要求，或是在遠端情況下，攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式，但會要求使用者重新導向要求私人資訊，例如帳戶號碼和密碼，接著會將這些資訊回傳給攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Open Redirect： 允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚的攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1.資料透過不受信任的來源進入 Web 應用程式，通常是 HTTP 要求。



2.HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給 Web 使用者。



與許多軟體的安全性弱點一樣，Cookie Manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者將惡意資料傳送至容易受到攻擊的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與 Cross-Site Request Forgery 之類的攻擊結合時，攻擊者可能變更、新增合法使用者的 Cookie 或甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應標頭的緣故，Cookie Manipulation 攻擊還可能導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在標頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應的剩餘標頭和本文，還允許他們建立完全在他們控制下的其他回應。

現今許多新型的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。例如，如果您嘗試使用禁用的字元設定標頭，最新版的 Apache Tomcat 會擲回 IllegalArgumentException。如果應用程式伺服器可防止使用換行字元來設定標頭，則您的應用程式面對 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選換行字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力，所以透過使用者輸入設定 HTTP 標頭時，仍需特別注意。

範例 1：以下程式碼區段會從 HTTP 要求中讀取部落格項目的作者名稱 (author)，並且將該名稱設定在 HTTP 回應的 Cookie 標頭中。

...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...

假設在要求中提交了一個由標準英數字元所組成的字串，例如「Jane Smith」，則包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 Cookie 的值是由未經驗證的使用者輸入而形成，所以只有當傳送給 author 的值不包含任何 CR 和 LF 字元時，回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯，第二個回應完全受到攻擊者所控制，而且可以使用所需的任何標頭和本文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：Cross-user Defacement、Web and Browser Cache Poisoning、Cross-site Scripting 和 Page Hijacking。

Cross-User Defacement：攻擊者可以發出一個要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解讀成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己提交惡意要求；或是在遠端情況下，攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為，但會將隱私資訊 (例如帳戶和密碼) 重新導向回攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如 Proxy 伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣地，如果回應快取到單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意內容，直到清除該快取項目為止，但是只有本機瀏覽器執行個體的使用者會受到影響。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器所產生且原本應供使用者使用的敏感內容，轉而供攻擊者使用。攻擊者藉由提交一個要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，致使中間節點 (例如共用的 Proxy 伺服器) 錯誤地將本應傳送給使用者的伺服器產生的回應傳送給攻擊者。因為攻擊者所提出的要求產生兩個回應，因此第一個被解譯為回應攻擊者的要求，而第二個則被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者將第二個要求傳送到伺服器，Proxy 伺服器會使用伺服器針對受害者產生的要求回應伺服器，如此一來，就會危及原本針對受害者的回應標頭或本文中的敏感資訊。

Open Redirect：允許未經驗證的輸入控制重新導向中所使用的 URL 有助於網路釣魚攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給網頁使用者。

與許多軟體的安全性弱點一樣，Cookie manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭，Cookie manipulation 攻擊還會導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說，如果您嘗試使用禁用的字元設定表頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並在 HTTP 回應的 Cookie 表頭中設定該名稱。

protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 cookie 的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己傳遞惡意要求，或是在遠端情況下，攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式，但會要求使用者重新導向要求私人資訊，例如帳戶號碼和密碼，接著會將這些資訊回傳給攻擊者。

快取破壞：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

開放式重新導向：允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給網頁使用者。

與許多軟體的安全性弱點一樣，Cookie manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭，Cookie manipulation 攻擊還會導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說，如果您嘗試使用禁用的字元設定表頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並且將該名稱設定在 HTTP 回應的 Cookie 表頭中。

  <cfcookie name = "author"
  value = "#Form.author#"
  expires = "NOW">  

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 cookie 的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己傳遞惡意要求，或是在遠端情況下，攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式，但會要求使用者重新導向要求私人資訊，例如帳戶號碼和密碼，接著會將這些資訊回傳給攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Open Redirect： 允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚的攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1.資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2.HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給 Web 使用者。

與許多軟體的安全性弱點一樣，Cookie Manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者將惡意資料傳送至容易受到攻擊的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與 Cross-Site Request Forgery 之類的攻擊結合時，攻擊者可以變更、新增合法使用者的 Cookie 或甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應標頭的緣故，Cookie Manipulation 攻擊還可能導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在標頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送之回應的剩餘標頭和正文，還允許它們全權建立其他回應。

現今許多新型的應用程式伺服器可防止將惡意字元插入 HTTP 標頭。舉例來說，如果您嘗試使用禁用的字元設定標頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用換行字元來設定標頭，則您的應用程式面對 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選換行字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirect 攻擊無招架能力，所以透過使用者輸入設定 HTTP 標頭時，仍需特別注意。

範例：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並且將該名稱設定在 HTTP 回應的 Cookie 標頭中。

...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
  Name:       "author",
  Value:      author,
  Domain:     "www.example.com",
}
http.SetCookie(w, &cookie)
...

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 Cookie 的值是由未經驗證的使用者輸入而得來，所以只有當提交給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元時，回應才會保留這種形式。若攻擊者提交惡意字串，例如 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯，第二個回應完全受到攻擊者所控制，而且可以使用所需的任何標頭和正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

Cross-User Defacement：攻擊者可以發出一個要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解讀成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己提交惡意要求；或是在遠端情況下，攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為，但會將隱私資訊 (例如帳號和密碼) 重新導向回攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如 Proxy 伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣地，如果回應快取到單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意內容，直到清除該快取項目為止，但是只有本機瀏覽器實例的使用者會受到影響。

Cross-Site Scripting：在攻擊者控制應用程式傳送的回應之後，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，攻擊者還可以利用具有相同本質的弱點，重新導向伺服器所產生且原本供使用者使用的敏感內容，轉而供攻擊者使用。攻擊者藉由提交一個要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，致使中間節點 (例如共用的 Proxy 服務器) 錯誤地將本應傳送給使用者的伺服器產生的回應傳送給攻擊者。因為攻擊者所提出的要求產生兩個回應，因此第一個被解譯為回應攻擊者的要求，而第二個則被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者將第二個要求傳送到伺服器，Proxy 伺服器會使用伺服器針對受害者產生的要求回應伺服器，如此一來，就會危及原本針對受害者的回應標頭或本文中的敏感資訊。

Open Redirect：允許未經驗證的輸入控制重新導向中所使用的 URL，有助於網路釣魚攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給網頁使用者。

與許多軟體的安全性弱點一樣，Cookie manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭，Cookie manipulation 攻擊還會導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說，如果您嘗試使用禁用的字元設定表頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例 1：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並且將該名稱設定在 HTTP 回應的 Cookie 表頭中。

String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
     cookie.setMaxAge(cookieExpiration);
     response.addCookie(cookie);

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 cookie 的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

有人認為在行動環境中，典型的 Web 應用程式弱點 (例如 Header Manipulation 與 Cookie Manipulation) 不會產生影響，因為使用者為何會攻擊自己呢？但是請謹記，行動平台的本質是從多種來源下載，並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高，這必然會擴大行動應用程式的受攻擊面，將程序之間的通訊包括在內。

範例 2：以下程式碼改寫 Example 1 以適用於 Android 平台。

...
	CookieManager webCookieManager = CookieManager.getInstance();
        String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
	String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
        webCookieManager.setCookie(url, setCookie);

...

跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己傳遞惡意要求，或是在遠端情況下，攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式，但會要求使用者重新導向要求私人資訊，例如帳戶號碼和密碼，接著會將這些資訊回傳給攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Open Redirect： 允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚的攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給網頁使用者。

與許多軟體的安全性弱點一樣，Cookie manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭，Cookie manipulation 攻擊還會導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說，如果您嘗試使用禁用的字元設定表頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並且將該名稱設定在 HTTP 回應的 Cookie 表頭中。

author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 cookie 的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

Cross-User Defacement：攻擊者可以發出一個要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解讀成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己提交惡意要求；或是在遠端情況下，攻擊者和使用者共用相同的連線到伺服器 (例如共用的 Proxy 伺服器) 的 TCP 連線。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式的行為，但會將隱私資訊 (例如帳戶和密碼) 重新導向回攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Open Redirect： 允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚的攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給網頁使用者。

與許多軟體的安全性弱點一樣，Cookie manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭，Cookie manipulation 攻擊還會導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說，如果您嘗試使用禁用的字元設定表頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並且將該名稱設定在 HTTP 回應的 Cookie 表頭中。

<?php
    $author = $_GET['AUTHOR_PARAM'];
    ...
    header("author: $author");
?>

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 cookie 的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己傳遞惡意要求，或是在遠端情況下，攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式，但會要求使用者重新導向要求私人資訊，例如帳戶號碼和密碼，接著會將這些資訊回傳給攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Open Redirect： 允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚的攻擊。

Header Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP 回應表頭包含的資料在未經驗證的情況下，便將其傳送給網頁使用者。

如同其他軟體的安全性弱點，Header Manipulation 是達到目的的一種手段，而不是一個目的。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP 回應表頭中。

最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例：以下程式碼片段會讀取 HTTP 要求中的位置，並在 HTTP 回應的位置欄位表頭中設定該位置。

    location = req.field('some_location')
    ...
    response.addHeader("location",location)

假設在要求中提交了一個由標準英數字元所組成的字串，如「index.html」，那麼包含這個 Cookie 的 HTTP 回應可能會以下列形式表示：

HTTP/1.1 200 OK
...
location: index.html
...

不過，因為位置的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 some_location 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「index.html\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己傳遞惡意要求，或是在遠端情況下，攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式，但會要求使用者重新導向要求私人資訊，例如帳戶號碼和密碼，接著會將這些資訊回傳給攻擊者。

Cache Poisoning：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

Open Redirect： 允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚的攻擊。

Cookie Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入 Web 應用程式，通常是 HTTP 要求。

2. HTTP Cookie 包含的資料在未經驗證的情況下，便傳送給網頁使用者。

與許多軟體的安全性弱點一樣，Cookie manipulation 是達到目的的一種手段，而不是目的本身。此弱點的基礎很簡單：攻擊者傳送惡意資料至有弱點的應用程式，應用程式再將該資料包含於 HTTP Cookie 中。

Cookie Manipulation：與跨網站偽造要求之類的攻擊結合時，攻擊者可能變更、新增至合法使用者的 Cookie，甚至覆寫合法使用者的 Cookie。

由於 HTTP 回應表頭，Cookie manipulation 攻擊還會導致其他類型的攻擊，例如：

HTTP Response Splitting：
最常見的一種 Header Manipulation 攻擊為 HTTP Response Splitting。為了成功進行 HTTP Response Splitting 攻擊，應用程式必須允許輸入在表頭中包含 CR (Carriage Return，亦由 %0d 或 \r 指定) 與 LF (Line Feed，亦由 %0a 或 \n 指定) 字元。這些字元不僅讓攻擊者控制應用程式接下來要傳送的回應表頭和回應主題，還允許他們全權建立其他回應。

現今許多先進的應用程式伺服器可防止將惡意字元插入 HTTP 表頭。舉例來說，如果您嘗試使用禁用的字元設定表頭，最新版的 Apache Tomcat 會拋出 IllegalArgumentException。如果應用程式伺服器可防止使用新行的字元來設定表頭，則您的應用程式對於 HTTP Response Splitting 的攻擊，具有一定的防禦能力。但是，僅篩選新行的字元，應用程式可能仍對 Cookie Manipulation 或 Open Redirects 攻擊無招架能力，所以透過使用者輸入設定 HTTP 表頭時，仍需特別注意。

範例：以下程式碼區段會從 HTTP 要求中讀取網路部落格項目的作者名稱 (author)，並在 HTTP 回應的 Cookie 表頭中設定該名稱。

...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...

假設在要求中提交了一個由標準英數字元所組成的字串，如 "Jane Smith"，那麼包含這個 Cookie 的 HTTP 回應可能會採用以下形式：

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

不過，因為 cookie 的值是由未經驗證的使用者輸入而得來，所以只有當傳送給 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字元，那麼回應才會保留這種形式。若攻擊者提交惡意字串，例如「Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...」，則 HTTP 回應將分割為以下形式的兩種回應：

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

很明顯的，第二個回應完全被攻擊者所控制，並且能使用任何標頭和想要的正文內容來建構。攻擊者可以建構任何 HTTP 回應，並造成不同的攻擊結果，這些攻擊包括：跨用戶塗改、網頁和瀏覽器快取記憶體下毒、Cross-site scripting 和網頁劫持。

跨用戶塗改：攻擊者將能夠發出單一要求到易受攻擊的伺服器，讓伺服器建立兩個回應，其中第二個回應可能會被錯誤解譯成針對不同要求的回應，該要求可能是由另一個與伺服器共用相同 TCP 連線的使用者所發出的。這種攻擊可以下列方式達成：攻擊者誘導使用者自己傳遞惡意要求，或是在遠端情況下，攻擊者和使用者共用相同的 TCP 連線連接到伺服器 (例如共用的代理伺服器)。最理想的情況是，攻擊者可能利用此功能讓使用者確信他們的應用程式已受攻擊，造成使用者對應用程式的安全性失去信心。最差的狀況是，攻擊者可能會提供特殊處理過的內容。這些內容專門用來模仿應用程式執行方式，但會要求使用者重新導向要求私人資訊，例如帳戶號碼和密碼，接著會將這些資訊回傳給攻擊者。

快取破壞：如果將惡意建構的回應快取到多個使用者使用的網頁快取或甚至單一使用者的瀏覽器快取，那麼影響所及會更大。如果將回應快取到共用網頁快取中 (例如代理伺服器中常見的網頁快取)，那麼該快取的所有使用者將會繼續收到惡意內容，直到清除該快取項目為止。同樣的，如果回應貯存在單一使用者的瀏覽器中，那麼該使用者會繼續收到惡意的內容，直到清除快取項目為止，雖然只會影響本機瀏覽器實例的使用者。

Cross-Site Scripting：一旦攻擊者可以控制應用程式傳送的回應，他們就可以提供各種惡意內容給使用者。Cross-Site Scripting 是最常見的攻擊形式，此類攻擊會在回應中包含惡意的 JavaScript 或其他程式碼，且會在使用者的瀏覽器中執行。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。對於易受攻擊應用程式的使用者而言，最常見且最危險的攻擊方法就是使用 JavaScript 將階段作業與驗證資訊傳回給之後可以完全掌控受害者帳戶的攻擊者。

網頁劫持：除了利用易受攻擊的應用程式傳送惡意內容給使用者外，還可以利用具有相同本質的弱點，重新導向伺服器產生原本供使用者使用的敏感內容，轉而供攻擊者使用。藉由提交要求產生兩個回應，伺服器預期的回應和攻擊者產生的回應，攻擊者可能造成一個中間節點，例如一個共用的代理伺服器，來誤導伺服器針對使用者產生的回應傳遞給攻擊者。因為攻擊者所提出的要求產生兩個回應，第一個被解譯回應攻擊者的要求，而第二個被忘卻。當使用者透過相同 TCP 連線發出合法要求時，攻擊者的要求已處於等待狀態，並會被解讀成針對受害者要求的回應。接著，攻擊者會將第二個要求傳送到伺服器，且代理伺服器會將伺服器原本針對受害者要求產生的回應當作第二個要求的回應，如此一來，就會危及原本針對受害者的回應表頭或主體中的敏感資訊。

開放式重新導向：允許未經驗證的輸入來控制重新導向中使用的 URL，如此會助長網路釣魚攻擊。

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

範例 1：以下配置顯示了使用萬用字元指定允許應用程式與哪些網域通訊。

  <configuration>
   <system.webServer>
     <httpProtocol>
       <customHeaders>
         <add name="Access-Control-Allow-Origin" value="*" />
       </customHeaders>
     </httpProtocol>
   </system.webServer>
  </configuration>

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

在 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 存取。

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

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

  <?php
    header('Access-Control-Allow-Origin: *');
  ?>

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

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

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

response.addHeader("Access-Control-Allow-Origin", "*")

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

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

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

  Response.AddHeader "Access-Control-Allow-Origin", "*"

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

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
    DATA: r TYPE REF TO cl_abap_random,
		  var1 TYPE i,
		  var2 TYPE i,
		  var3 TYPE n.


	GET TIME.
	var1 = sy-uzeit.
	r = cl_abap_random=>create( seed = var1 ).
	r->int31( RECEIVING value = var2 ).
	var3 = var2.
    CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.

此程式碼使用 CL_ABAP_RANDOM->INT31 函數為其所產生的收據頁面產生「唯一」識別碼。由於 CL_ABAP_RANDOM 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

string GenerateReceiptURL(string baseUrl) {
    Random Gen = new Random();
    return (baseUrl + Gen.Next().toString() + ".html");
}

此程式碼使用 Random.Next() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Random.Next() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。

在安全性較高的環境中，將一個能夠產生可預測值的函數當作亂數來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

char* CreateReceiptURL() {
    int num;
    time_t t1;
    char *URL = (char*) malloc(MAX_URL);
    if (URL) {
        (void) time(&t1);
        srand48((long) t1);     /* use time to set seed */
        sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
    }
    return URL;
}

此程式碼使用 lrand48() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 lrand48() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。


電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>

此程式碼使用 Rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容。但是，它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來處理這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：下列程式碼使用統計式 PRNG 來建立 RSA 金鑰。

import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)

此程式碼使用 rand.New() 函數為 RSA 金鑰產生隨機性。由於 rand.New() 是統計式 PRNG，所以攻擊者很容易就能猜到其所產生的值。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，因此很容易複製數值串流，因此不適用於安全性取決於所產生數值的不可預測性的環境。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下 Spring Boot 組態設定檔案使用統計式 PRNG 建立安全性要求較高的權杖。

my.secret=${random.value}

此程式碼使用 Random.next() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Random.next() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密型 PRNG)，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

function genReceiptURL (baseURL){
  var randNum = Math.random();
  var receiptURL = baseURL + randNum + ".html";
  return receiptURL;
}

此程式碼使用 Math.random() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Math.random() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立 URL。

fun GenerateReceiptURL(baseUrl: String): String {
    val ranGen = Random(Date().getTime())
    return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}

此程式碼使用 Random.nextInt() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Random.nextInt() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密型 PRNG)，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

  function genReceiptURL($baseURL) {
    $randNum = rand();
    $receiptURL = $baseURL . $randNum . ".html";
    return $receiptURL;
  }

此程式碼使用 rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。

在安全性較高的環境中，將一個能夠產生可預測值的函數當作亂數來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
  RETURN VARCHAR2
AS
  rnum VARCHAR2(48);
  time TIMESTAMP;
  url VARCHAR2(MAX_URL)
BEGIN
  time := SYSTIMESTAMP;
  DBMS_RANDOM.SEED(time);
  rnum := DBMS_RANDOM.STRING('x', 48);
  url := 'http://test.com/' || rnum || '.html';
  RETURN url;
END

此程式碼使用 DBMS_RANDOM.SEED() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 DBMS_RANDOM.SEED() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

    def genReceiptURL(self,baseURL):
        randNum = random.random()
        receiptURL = baseURL + randNum + ".html"
        return receiptURL

此程式碼使用 rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

def generateReceiptURL(baseUrl) {
  randNum = rand(400000000)
  return ("#{baseUrl}#{randNum}.html");
}

此程式碼使用 Kernel.rand() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Kernel.rand() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計 PRNG 來建立隨機值，此值將用作重設密碼權杖。

    sqlite3_randomness(10, &reset_token)

在安全性要求較高的環境中，將一個能夠產生可預測值的函數當作隨機來源使用時，會產生 Insecure Randomness 錯誤。

電腦是一種決定性的機器，因此不可能產生真正的隨機性。虛擬亂數產生器 (PRNG, Pseudorandom Number Generator) 近似於隨機演算，會從一個可以計算後續值的種子開始。

PRNG 包括兩種類型：統計式和加密式。統計式 PRNG 可提供有用的統計內容，但是它們的輸出很容易預測，導致複製數值串流很容易。因此，對於因安全性由產生數值決定而導致其不可預測的環境，其並不適用。加密式 PRNG 則會藉由產生更難以預測的輸出來解決這個問題。若要對數值進行加密保護，必須使攻擊者無法或難以區別產生的隨機數值和真實的隨機數值。一般來說，如果沒有指出某個 PRNG 演算法經過加密保護，那麼它很可能是統計式 PRNG，不應在安全性要求較高的環境中使用，否則會引發嚴重弱點，例如易猜的臨時密碼、容易預測的加密金鑰、Session Hijacking 以及 DNS 欺騙。

範例：以下程式碼使用統計式 PRNG，為購買後仍在有效期內的收據建立一個 URL。

...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...

此程式碼使用 Rnd() 函數為其所產生的收據頁面產生「唯一」識別碼。由於 Rnd() 是統計式 PRNG，攻擊者很容易就能猜到其所產生的字串。雖然收據系統的基礎設計也存在錯誤，但是如果它使用一個不會產生可預測收據識別碼的亂數產生器 (例如加密式 PRNG)，那就會安全很多。

這些函數可產生隨機值或虛擬隨機值 (已向這些值傳送種子)，不應使用常數引數呼叫這些函數。如果使用特定常數值向虛擬亂數產生器 (例如 CL_ABAP_RANDOM 類別或其變體) 提供種子，則可收集大量 PRNG 輸出的攻擊者將可預測由 GET_NEXT、INT 和用於傳回或指派值的類似方法傳回的值。

範例 1：在以下內容中，自物件 random_gen1 可以預測由物件 random_gen2 產生的值。

		DATA: random_gen1 TYPE REF TO cl_abap_random,
			  random_gen2 TYPE REF TO cl_abap_random,
			  var1 TYPE i,
			  var2 TYPE i.

		random_gen1 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen1->int
				RECEIVING
			value  = var1.

			WRITE:/ var1.
		ENDDO.

		random_gen2 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen2->int
				RECEIVING
			value  = var2.

			WRITE:/ var2.
		ENDDO.

在此範例中，虛擬亂數產生器：random_gen1 和 random_gen2 被提供完全相同的種子，因此 var1 = var2

這些函數可產生隨機值或虛擬隨機值 (已向這些值傳送種子)，不應使用常數引數呼叫這些函數。如果使用特定值 (使用類似 srand(unsigned int) 的函數) 向虛擬亂數產生器 (例如 rand()) 提供種子，則可收集大量 PRNG 輸出的攻擊者將可預測由 rand() 和用於傳回或指派值的類似方法傳回的值。

範例 1：由虛擬亂數產生器產生的值在前兩個區塊中是可預測的，因為這兩個區塊以相同的種子開始。

        srand(2223333);
        float randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);
        randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);

        srand(2223333);
        float randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);
        randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);

        srand(1231234);
        float randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);
        randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);

在此範例中，randomNum1 和 randomNum2 的結果以完全相同的方式提供種子，因此在向虛擬亂數產生器 srand(2223333) 提供種子的呼叫後，每次對 rand() 的呼叫都將按照相同的呼叫順序產生相同的輸出。例如，輸出可能如下所示：

Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00

這些結果並不隨機。

這些函數可產生隨機值或虛擬隨機值 (已向這些值傳送種子)，不應使用常數引數呼叫這些函數。如果虛擬亂數產生器 (PRNG) 以特定值 (使用 math.Rand.New(Source) 等函數) 作為種子，則可收集大量 PRNG 輸出的攻擊者將可預測由 math.Rand.Int() 和用於回傳或指派值的類似方法回傳的值。

範例 1：由虛擬亂數產生器產生的值在前兩個區塊中是可預測的，因為這兩個區塊以相同的種子開始。

  randomGen := rand.New(rand.NewSource(12345))
  randomInt1 := randomGen.nextInt()
  
  randomGen.Seed(12345)
  randomInt2 := randomGen.nextInt()

在此範例中，以完全相同的方式向 PRNG 提供種子，因此，在向虛擬亂數產生器 (randomGen.Seed(12345)) 提供種子的呼叫後，每次對 nextInt() 的呼叫都按照相同的順序產生相同的輸出。

這些函數可產生隨機值或虛擬隨機值 (已向這些值傳送種子)，不應使用常數引數呼叫這些函數。如果使用特定值 (使用 Random.setSeed() 等的函數) 向虛擬亂數產生器 (例如 Random) 提供種子，則可收集大量 PRNG 輸出的攻擊者將可預測由 Random.nextInt() 和用於回傳或指派值的類似方法回傳的值。

範例 1：自 Random 物件 randomGen1 可以預測由 Random 物件 randomGen2 產生的值。

        Random randomGen1 = new Random();
        randomGen1.setSeed(12345);
        int randomInt1 = randomGen1.nextInt();
        byte[] bytes1 = new byte[4];
        randomGen1.nextBytes(bytes1);

        Random randomGen2 = new Random();
        randomGen2.setSeed(12345);
        int randomInt2 = randomGen2.nextInt();
        byte[] bytes2 = new byte[4];
        randomGen2.nextBytes(bytes2);

在此範例中，虛擬亂數產生器：randomGen1 與 randomGen2 以完全相同的方式提供種子，因此 randomInt1 == randomInt2 以及陣列 bytes1[] 與 bytes2[] 的對應值相等。

這些函數可產生隨機值或虛擬隨機值 (已向這些值傳送種子)，不應使用常數引數呼叫這些函數。如果使用特定值 (使用 Random(Int) 等的函數) 向虛擬亂數產生器 (例如 Random) 提供種子，則可收集大量 PRNG 輸出的攻擊者將可預測由 Random.nextInt() 和用於回傳或指派值的類似方法回傳的值。

範例 1：自 Random 物件 randomGen1 可以預測由 Random 物件 randomGen2 產生的值。

        val randomGen1 = Random(12345)
        val randomInt1 = randomGen1.nextInt()
        val byteArray1 = ByteArray(4)
        randomGen1.nextBytes(byteArray1)

        val randomGen2 = Random(12345)
        val randomInt2 = randomGen2.nextInt()
        val byteArray2 = ByteArray(4)
        randomGen2.nextBytes(byteArray2)

在此範例中，虛擬亂數產生器：randomGen1 與 randomGen2 以完全相同的方式提供種子，因此 randomInt1 == randomInt2 以及陣列 byteArray1 與 byteArray2 的對應值相等。

這些函數可產生虛擬隨機值 (已向這些值傳送種子)，不應使用常數整數引數呼叫這些函數。如果使用特定值向虛擬亂數產生器提供種子，則傳回的值是可預測的。

範例 1：由虛擬亂數產生器產生的值在前兩個區塊中是可預測的，因為這兩個區塊以相同的種子開始。

...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...

在此範例中，以完全相同的方式向 PRNG 提供種子，因此，在向虛擬亂數產生器 (random.seed(123456)) 提供種子的呼叫後，每次對 randint() 的呼叫都將按照相同的順序在同一輸出中產生相同的輸出。例如，輸出可能如下所示：

Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3

這些結果並不隨機。

不應使用受感染的引數初始化類別 CL_ABAP_RANDOM (或其變體)。否則，攻擊者會藉此控制用於為虛擬亂數產生器提供種子的值，從而推測透過呼叫以下 (包括但不限於) 方法所產生的值的序列： GET_NEXT, INT, FLOAT, PACKED.

這些函數可產生隨機或虛擬隨機值 (例如 rand()) (它們會被傳送種子 (例如 srand()))，不應使用受感染的引數來呼叫這些函數。否則，攻擊者會藉此控制用於為虛擬亂數產生器提供種子的值，從而推測透過呼叫虛擬亂數產生器所產生的值 (通常是整數) 的序列。

產生虛擬隨機值 (例如 ed25519.NewKeyFromSeed()) 的函數；不應使用受感染的引數呼叫這些函數。否則，攻擊者會藉此控制用於為虛擬亂數產生器提供種子的值，從而推測透過呼叫虛擬亂數產生器所產生的值的序列。

不應使用受感染的整數引數呼叫 Random.setSeed()。否則，攻擊者會藉此控制用於為虛擬亂數產生器提供種子的值，從而能推測透過呼叫 Random.nextInt()、Random.nextShort()、Random.nextLong() 所產生、由 Random.nextBoolean() 傳回或 Random.nextBytes(byte[]) 中設定的值 (通常是整數) 的序列。

不應使用受感染的整數引數呼叫 Random.setSeed()。否則，攻擊者會藉此控制用於為虛擬亂數產生器提供種子的值，從而能推測透過呼叫 Random.nextInt()、Random.nextLong()、Random.nextDouble() 所產生、由 Random.nextBoolean() 回傳或 Random.nextBytes(ByteArray) 中設定的值 (通常是整數) 的序列。

產生虛擬隨機值 (例如 random.randint()) 的函數；不應使用受感染的引數呼叫這些函數。否則，攻擊者會藉此控制用於為虛擬亂數產生器提供種子的值，從而能夠預測透過呼叫虛擬亂數產生器所產生的值 (通常是整數) 的序列。

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此其安全性會降低，特別是在行動環境中，裝置經常使用 WiFi 連線連接到不安全且公開的無線網路。在這些情況下，應使用加密 (安全) 通訊協定。

範例 1：以下範例會透過 HTTP 通訊協定來傳送資料 (而非使用 HTTPS)。

...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...

傳入的 HttpResponse 物件 res 可能會遭到破解，因為它是透過未加密和未經驗證的通道傳遞。

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此易受 man-in-the-middle 攻擊，因為裝置經常使用 WiFi 連線連接到不安全且公開的無線網路。

範例 1：以下程式碼使用不安全的 HTTP 通訊協定 (而非使用 HTTPS)：

    var account = new CloudStorageAccount(storageCredentials, false);

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此其安全性會降低，特別是在行動環境中，裝置經常使用 WiFi 連線連接到不安全且公開的無線網路。

範例 1：以下範例會透過 HTTP 通訊協定來讀取資料 (而非使用 HTTPS)。

  ...
  String url = 'http://10.0.2.2:11005/v1/key';
  Response response = await get(url, headers: headers);
  ...

傳入的回應 response 安全性可能降低，因為它是透過未加密和未經驗證通道傳遞。

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此其安全性會降低，特別是在裝置經常連線到不安全且公開的無線網路環境中。

範例 1：以下範例會透過 HTTP 通訊協定來設定 Web 伺服器 (而非使用 HTTPS)。

	helloHandler := func(w http.ResponseWriter, req *http.Request) {
		io.WriteString(w, "Hello, world!\n")
	}

	http.HandleFunc("/hello", helloHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此其安全性會降低，特別是在行動環境中，裝置經常使用 WiFi 連線連接到不安全且公開的無線網路。

範例 1：以下 Spring Boot 組態設定檔案停用 TLS 通訊協定，並因此使用 HTTP 通訊協定。

server.ssl.enabled=false

範例 2：以下 Spring 組態檔要求使用 HTTP 通訊協定。

      <intercept-url pattern="/member/**"  access="ROLE_USER" requires-channel="http"/>

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此其安全性會降低，特別是在行動環境中，裝置經常使用 WiFi 連線連接到不安全且公開的無線網路。

範例 1： 以下範例會透過 HTTP 通訊協定來讀取資料 (而非使用 HTTPS)。

var http = require('http');
...
http.request(options, function(res){
  ...
});
...

傳入的 http.IncomingMessage 物件 res 安全性可能降低，因為它是透過未加密和未經驗證通道傳遞。

所有透過 HTTP 傳送的資料皆是以清楚且易受攻擊的方式傳送。

範例 1：以下範例會透過 HTTP 協定來傳送資料 (與 HTTPS 比較)。

NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此其安全性會降低，特別是在裝置經常連線到不安全且公開的無線網路環境中。

範例 1：以下範例將停用通訊端上的加密。

...
stream_socket_enable_crypto($fp, false);
...

使用不安全、未加密或純文字通訊協定傳送的所有通訊，安全性都會降低。

經由 HTTP、FTP 或 gopher 進行的所有通訊皆未經驗證且未加密。因此，其安全性會降低。

範例 1： 以下範例會透過 HTTP 通訊協定來讀取資料 (而非使用 HTTPS)。

require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...

傳入的串流 in 安全性可能降低，因為它是透過未加密和未經驗證通道傳遞。

所有透過 HTTP 傳送的資料皆是以清楚且易受攻擊的方式傳送。

範例 1：以下範例會透過 HTTP 協定來傳送資料 (與 HTTPS 比較)。

let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)

JSONP 在設計上，會允許執行跨網域要求，但缺乏限制和驗證要求來源的任何機制。惡意網站可代表使用者輕易執行 JSONP 要求並處理 JSON 回應。基於這個原因，極力建議您在傳送 PII 或敏感資料時，避免使用此通訊技術。
JSONP 在設計上是一種自我強加 XSS 攻擊，因為收回 (callback) 函數名稱需要反映給要求網站，才能正確進行 JSON 處理。為了避免 JavaScript 注入，必須要驗證和處理收回 (callback) 函數。JSONP 在設計上是一種自我強加 XSS 攻擊，因為收回 (callback) 函數名稱需要反映給要求網站，才能正確進行 JSON 處理。