Header Manipulation: Cookies

在 Cookie 中包含未經驗證的資料會導致 HTTP 回應 Header manipulation，並引發 Cache-Poisoning、Cross-Site Scripting、Cross-User Defacement、Page Hijacking、Cookie Manipulation 或 Open Redirect。

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，如此會助長網路釣魚的攻擊。