解密CSRF、CORS和HTTP安全標頭 - vnaik

CSRF
跨站點請求偽造CSRF是一種攻擊，其中第三方迫使使用者對他們當前登入的網站執行操作。
這是一個說明其工作原理的示例：

1. 您訪問evil.com
2. evil.com有一個隱藏的表單，該表單會在頁面載入時提交到mybank.com/transfer-funds。由於您已經登入到mybank.com，因此此請求是使用mybank.com cookie發出的，將以靜默方式從您的帳戶中進行轉帳。
3. 由於“ evil.com ”和“ mybank.com ”的來源不同，因此瀏覽器拒絕提供對evil.com的響應（由於存在CORS），但攻擊者不在乎，這筆錢已經在“mybank.com”轉移了。

1. 每次mybank.com向使用者提供表單時，它都會生成CSRF令牌並將其插入表單中的隱藏欄位中
2. 當mybank.com收到POST請求，它將根據其資料庫檢查CSRF令牌-如果該令牌存在且有效，則請求透過。如果CSRF令牌丟失或不正確，它將被拒絕。

CORS
跨域請求共享CORS僅適用於瀏覽器場景，是一種安全機制，允許一個來源向另一個來源發出請求。所有瀏覽器都遵循“單一來源策略”，這意味著預設情況下指令碼無法向其他來源發出請求-但是，如果伺服器提供了正確配置的CORS標頭，則可以有選擇地放寬此策略。因此，CORS是有選擇地放鬆安全性而不是加強安全性的一種方法。
當網站向另一個來源發出XHR請求時，瀏覽器會首先啟動預檢OPTIONS請求-僅當伺服器以允許的來源列表響應該預檢時，才發出原始請求，並且該列表包含當前來源頁。
請注意，瀏覽器不會為具有預設標頭的GET HEAD POST請求發出CORS預檢請求。
作為對OPTIONS請求的響應而傳送的一些關鍵標頭：

• access-control-allow-credentials：如果設定，則cookie由瀏覽器傳送
• access-control-allow-origin：允許發出請求的來源列表，或“ *”允許任何人發出請求的來源。如果設定了access-control-allow-credentials，則不能將其設定為“ *”，否則瀏覽器將拒絕該請求
• access-control-allow-methods：允許通訊的HTTP方法列表-POST，PUT等。

XSS
跨站點指令碼攻擊XSS是一種攻擊，攻擊者將客戶端指令碼注入到網頁中。XSS可用於繞過同源策略和CSRF保護。
這可以透過破壞伺服器（例如，透過使用已知的漏洞利用）或利用不良的使用者輸入來向網站新增指令碼來完成，只要使用者訪問該網站就會觸發該指令碼。
這是最常被利用的漏洞，可以透過仔細的清理和編碼來修復，以顯示所有使用者輸入-即使像電子郵件地址之類的東西也可能是指令碼注入的媒介。例如。，

"><script>alert(1);</script>"@example.org

防止XSS的OWASP速查表是確保應用程式免受XSS攻擊的良好起點。
 

CSP
內容安全策略是檢測和緩解XSS攻擊的附加安全層。透過指定應被視為指令碼有效來源的域，Web瀏覽器將僅執行從這些白名單域載入的指令碼。CSP可以為所有動態原點指定允許的原點，包括指令碼，樣式表，影像，字型，物件，媒體（音訊，影片），框架，甚至是表單動作。
CSP是透過Content-Security-Policy HTTP標頭設定的。
與CORS的區別在於，CORS阻止訪問第三方伺服器，而CSP阻止網站本身從第三方載入內容，以防禦XSS。
CSP不是針對XSS的靈丹妙藥，但它可以幫助您。最終，需要透過仔細的應用程式設計和有效的使用者輸入衛生防護（在前端和後端）來防止XSS。
CSP由於其選擇的深度而最複雜，而且可能也是最難實施的，因為每次前端開發人員每次新增CDN資源（用於字型，指令碼等）時，它都會將CDN新增到CSP標頭中。如果沒有經過精心設計的測試設定，那麼在開發人員測試中就可以正常工作，但是在推向生產階段時就失敗了。
CSP非常複雜，需要不止幾個段落-整頁將更加合理。
在內容安全策略的網站介紹如何CSP支援新增到您的Web伺服器和谷歌的方便的測試工具可以幫助測試這些策略。
 

HSTS
HTTP嚴格傳輸安全性HSTS透過允許伺服器宣告瀏覽器應僅使用HTTPS連線與其進行互動，絕不使用HTTP，這樣來防禦協議降級攻擊和cookie劫持。並且瀏覽器應始終將所有使用HTTP的訪問嘗試都轉換為HTTPS，例如HTTPS。透過重寫所有連結以使用HTTPS代替HTTP。
透過透明地將http連線轉換為純https來防止竊聽和中間人攻擊。
例如，您可能連線到機場的免費wifi服務以訪問您的銀行網站，但訪問點實際上是駭客的膝上型電腦，該膝上型電腦會進行MITM攻擊並將您重定向到該銀行網站的克隆。只要您至少透過HTTPS訪問銀行網站一次（並且銀行使用HSTS），HSTS便會在這種情況下提供安全性，瀏覽器將完全拒絕此請求。
此頁面包含有關為Nginx配置HSTS的詳細資訊。
 

HPKP
HTTP公鑰固定HPKP可透過為瀏覽器提供一組公鑰來使HTTPS網站使用欺詐性獲得的SSL證照來抵制假冒，這是將來可信任的唯一連線到同一來源的公鑰。
與過去使用Comodo發生的情況一樣，這可提供安全保護，以防止受到破壞的證照頒發機構的侵害。
在上述機場場景中，如果駭客也有從銀行騙取的證照，則僅HSTS不能保護您-但是使用HPKP，即使這種攻擊也可以緩解。這是首次使用時信任的技術。
HPKP最終將被Expect-CT標頭取代。有關HPKP的更多資訊。
 

Set-Cookie
這是一個相當標準的標頭，到目前為止是頁面上最古老的標頭，但它也是正確配置最重要（也是最簡單）的標頭之一。
這可以透過設定一些指令來完成。

• SameSite: Strict指令抵禦來自所有跨域請求開啟cookie的CSRF攻擊。
• Secure 指令確保cookie的HTTPS連線只使用過的-從而提供了基於HPKP和HSTS的額外的安全性。
• HttpOnly指令確保JavaScript不能訪問cookie。

其他標頭
通常，這些設定不太重要，但需要注意。

• X-XSS Protection：此標頭已過時，可能有害，CSP在提供保護方面做得更好。Chrome的主要工作是觸發XSS稽核程式，該稽核程式由於不安全[url=https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TuYw-EZhO9g/blGViehIAwAJ]而被棄用[/url]。
• X-Frame-Options：此標頭指示是否應允許該網站在iFrame中顯示。這已被CSP的frame-ancestors選項所取代，該選項在現代瀏覽器中得到了更好的支援。
• X-Content-Type-Options：如果未設定Content-Type標頭，則可以防止瀏覽器嘗試猜測內容的型別。這可以防止允許使用者上傳和共享檔案的網站受到XSS攻擊。
• X-Download Options（X-下載選項）：在涉及上傳使用者檔案的場景中再次有用，當設定為“ noopen”時，這將強制瀏覽器下載檔案，而不是嘗試在瀏覽器中顯示該檔案。
• Referrer-Policy：將其設定為“ no-referrerer”時，瀏覽器在發出請求時不會傳送該Referrer，這對於保護隱私很有用。有關referrer-policy的更多資訊。