攻擊型別

點選劫持是一種欺騙使用者點選連結、按鈕等的行為，而這些連結、按鈕等並非使用者認為的真實內容。例如，這可以用來竊取登入憑據或讓使用者無意中安裝惡意軟體。（點選劫持有時被稱為“使用者介面改頭換面”，但這是對“改頭換面”一詞的錯誤使用。）

跨站指令碼 (XSS) 是一種安全漏洞，它允許攻擊者將惡意客戶端程式碼注入網站。此程式碼由受害者執行，並允許攻擊者繞過訪問控制和冒充使用者。根據開放式 Web 應用程式安全專案，XSS 是 2017 年第七大最常見的 Web 應用程式漏洞。

如果 Web 應用程式沒有采用足夠的驗證或編碼，這些攻擊就會成功。使用者的瀏覽器無法檢測到惡意指令碼不可信，因此它允許惡意指令碼訪問任何 Cookie、會話令牌或其他敏感的特定網站資訊，或者允許惡意指令碼重寫 HTML 內容。

跨站指令碼攻擊通常發生在 1) 資料透過不可信來源（最常見的是 Web 請求）進入 Web 應用程式時，或 2) 動態內容傳送到 Web 使用者時未經驗證是否存在惡意內容。

惡意內容通常包括 JavaScript，但有時也包括 HTML、Flash 或瀏覽器可以執行的任何其他程式碼。基於 XSS 的攻擊種類幾乎無限，但它們通常包括將私有資料（如 Cookie 或其他會話資訊）傳輸給攻擊者，將受害者重定向到攻擊者控制的網頁，或在易受攻擊網站的偽裝下在使用者計算機上執行其他惡意操作。

XSS 攻擊可以分為三類：儲存型（也稱為持久型）、反射型（也稱為非持久型）或 DOM 型。

儲存型 XSS 攻擊

注入的指令碼永久儲存在目標伺服器上。當瀏覽器傳送資料請求時，受害者隨後從伺服器檢索此惡意指令碼。

反射型 XSS 攻擊

當用戶被誘騙點選惡意連結、提交經過特殊製作的表單或瀏覽惡意網站時，注入的程式碼會傳送到易受攻擊的網站。Web 伺服器將注入的指令碼反射回使用者的瀏覽器，例如在錯誤訊息、搜尋結果或任何其他包含作為請求一部分發送到伺服器的資料的響應中。瀏覽器會執行程式碼，因為它假設響應來自使用者已互動過的“可信”伺服器。

DOM 型 XSS 攻擊

有效負載是由於修改了原始客戶端指令碼使用的 DOM 環境（在受害者的瀏覽器中）而執行的。也就是說，頁面本身不會發生變化，但頁面中包含的客戶端程式碼由於對 DOM 環境的惡意修改而以意外的方式執行。

CSRF（有時也稱為 XSRF）是一種相關的攻擊型別。攻擊者會導致使用者的瀏覽器在未經使用者同意或知情的情況下向網站後端發出請求。攻擊者可以使用 XSS 有效負載來發起 CSRF 攻擊。

維基百科提到了一個關於 CSRF 的好例子。在這種情況下，有人包含一張實際上不是影像的影像（例如在未過濾的聊天或論壇中），實際上它是一個向你的銀行伺服器發出取款請求。

<img
  src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />

現在，如果你登入了你的銀行賬戶，你的 Cookie 仍然有效（並且沒有其他驗證），你將在載入包含此影像的 HTML 時立即轉賬。對於需要 POST 請求的端點，可以以程式設計方式觸發 <form> 提交（可能在不可見的 <iframe> 中），當頁面載入時。

<form action="https://bank.example.com/withdraw" method="POST">
  <input type="hidden" name="account" value="bob" />
  <input type="hidden" name="amount" value="1000000" />
  <input type="hidden" name="for" value="mallory" />
</form>
<script>
  window.addEventListener("DOMContentLoaded", () => {
    document.querySelector("form").submit();
  });
</script>

有一些技術應該用於防止這種情況發生

• GET 端點應該是冪等的——執行更改而不是檢索資料的操作應該要求傳送 POST（或其他 HTTP 方法）請求。POST 端點不應該互換地接受帶有查詢字串中引數的 GET 請求。
• 伺服器應該向瀏覽器提供一個會話唯一的 CSRF 令牌。然後，這個令牌可以在瀏覽器釋出表單時包含（在 <form> 元素中隱藏的輸入欄位中）。對於所有可能執行操作的非 GET 請求，伺服器會將傳送的令牌與其為該會話儲存的值進行比較。如果出現不匹配，則請求會被中止。
• 這種保護方法依賴於攻擊者無法預測使用者的分配的 CSRF 令牌。令牌應該在登入時重新生成。
• 用於敏感操作的 Cookie（例如會話 Cookie）應該具有較短的生存期，並且 SameSite 屬性 設定為 Strict 或 Lax。在支援的瀏覽器中，這將確保會話 Cookie 不會與跨站點請求一起傳送，並且請求實際上對應用程式伺服器未經身份驗證。
• 應該部署 CSRF 令牌和 SameSite Cookie。這確保所有瀏覽器都受到保護，並提供 SameSite Cookie 無法提供幫助的保護（例如來自單獨子域的攻擊）。

有關更多預防技巧，請參閱 OWASP CSRF 預防備忘單。

第三方攔截 Web 伺服器和客戶端（瀏覽器）之間的流量，並冒充 Web 伺服器以捕獲資料（例如登入憑據或信用卡資訊）。流量被傳遞，可能會進行修改。開放式 Wi-Fi 網路是執行此攻擊的典型手段。

會話劫持是指訪問和濫用使用者的已認證會話。這可能是透過竊取現有會話的 Cookie，或透過欺騙使用者（或其瀏覽器）設定具有預定會話 ID 的 Cookie 來完成的。

可以透過部署嚴格的內容安全策略來限制洩露途徑。

第三方能夠確定使用者的會話識別符號（例如，透過讀取或設定它），因此可以像該使用者一樣與伺服器互動。竊取 Cookie 是實現此目的的一種方式。

請記住，諸如 application.example.com 之類的子域可以透過設定 Domain 屬性來設定 Cookie，以便與 example.com 或其他子域的請求一起傳送

Set-Cookie: CSRF=e8b667; Secure; Domain=example.com

如果易受攻擊的應用程式在子域上可用，則此機制可以在會話固定攻擊中被濫用。當用戶訪問父域（或其他子域）上的頁面時，應用程式可能會信任使用者 Cookie 中傳送的現有值。這可能允許攻擊者在使用者登入後繞過 CSRF 保護或劫持會話。或者，如果父域沒有使用 HTTP 嚴格傳輸安全 並且 includeSubdomains 設定為開啟，則受到主動 MitM 攻擊的使用者（可能連線到開放式 Wi-Fi 網路）可能會收到來自不存在子域的帶有 Set-Cookie 標頭的響應。最終結果將大致相同，瀏覽器會儲存非法 Cookie 並將其傳送到 example.com 下的所有其他頁面。

會話固定應該主要透過在使用者身份驗證時重新生成會話 Cookie 值（即使已經存在 Cookie）以及透過將任何 CSRF 令牌繫結到使用者來緩解。