隨手扎

你可能不知道的內容安全策略(Content-Security-Policy, CSP)

前言

當我們知道了XSS，瞭解到對於外部資源的引用檢查是何等重要。那麼除了開發上需要注意意外，還可以怎麼做？

服務器設置CSP相關回應頭

CSP，全名Content Security Policy，也就是內容安全政策。這是為了告訴瀏覽器，這個頁面允許什麼行為，讓瀏覽器幫忙在檢查一次。與設個相關的主要有兩個Response Headers：Content-Security-Policy和Content-Security-Policy-Report-Only。

Content-Security-Policy可以設定一些政策，當瀏覽器發現也面內容行為不符合這些政策的時候，就會被阻擋下來。

如果在一開始調整，有大量不確定受到影響的頁面，並不希望行為直接被阻擋下來，可以改先使用Content-Security-Policy-Report-Only。當發現不符合政策的頁面內容時，先發送到後端的一個端點記錄下來。再所有被發現存在問題的頁面都已經修正後，再改成設置為Content-Security-Policy。

繼續以前一個例子來用：A網站 http://a.127.0.0.1.nip.io:8000/index 有以下內容：

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8"/>
    <title>CSP</title>
    <link rel="stylesheet" href="http://b.127.0.0.1.nip.io:8000/xss.css" type="text/css" media="screen" />
  </head>
  <body>
    <h1>Hello, World</h1>
  </body>
  <script type="text/javascript" src="http://b.127.0.0.1.nip.io:8000/xss.js"></script>
</html>

這次也真夠糟糕的，引用到兩份B網站 http://b.127.0.0.1.nip.io:8000 存在問題的內容–/xss.css和/xss.css

在部署的時候可以在伺服器回應的HTTP Response加入Header:

Content-Security-Policy: defalut-src 'self';

這次這兩個不安全的內容就會被瀏覽器阻擋下來。

如果確定外部資源內容是需要的話該怎麼辦？

那麼可以將外部資源加入到允許來源裡面：

Content-Security-Policy: default-src http://b.127.0.0.1.nip.io:8000;

其實更好的方式是，將外部資源內容經過雜湊運算後，設定在內容安全政策裡面：

Content-Security-Policy: default-src 'self'; script-src 'sha384-+fv4uPD4wng0cm7Jy66oPnaKuxEawAdJRz3TEeFAXaNLuhb53x8RlNIhX6TuZrr2'; style-src 'sha384-cjur6vLG3ilgUU0OewWykkHkLF/tVELdTUSVlUGkl49AMczCbzIrkFRvL4BQ07ky';

這時候使用到外部資源的地方也需要申明雜湊值：

<link rel="stylesheet" href="http://b.127.0.0.1.nip.io:8000/xss.css" type="text/css" media="screen" integrity="sha384-cjur6vLG3ilgUU0OewWykkHkLF/tVELdTUSVlUGkl49AMczCbzIrkFRvL4BQ07ky" crossorigin="anonymous"/>
<script type="text/javascript" src="http://b.127.0.0.1.nip.io:8000/xss.js" integrity="sha384-+fv4uPD4wng0cm7Jy66oPnaKuxEawAdJRz3TEeFAXaNLuhb53x8RlNIhX6TuZrr2" crossorigin="anonymous"></script>

這麼做可以減緩外部資源不知不覺遭到更改為惡意內容的問題。

這原本是屬於SRI的檢驗方式，本來可以透過設定CSP: require-sri-for來處理，但是該方式已經被規範標記為棄用。在CSP 3.0規範中重新提到類似做法，不過我在Can I Use沒有查詢到相關普及度的表格，自己在Mozilla Firefox Browser嘗試也沒弄出個什麼結果Orz。

嘗試超級久的，結果才發現瀏覽器可能還不支援 (T_T)

結語

結果為了檢驗一些設定成果，也花上非常多的時間Orz

「內容安全政策」有非常多東西，請各位看官們往下參考參考資料啦~

另外，除了部署設定要好好考量相關政策該如何制定外，這部分實際是由瀏覽器檢查的。所以如果使用者是使用不安全的瀏覽器或執行環境，一切也就破功了。資訊安全不單單只是開發人員、維運人員的責任，使用者也很需要有一定意識。

最後，引用一段其中一個參考資料的內容：

真的建議認真評估一下是否為了省一點小流量而去使用這些外部JS library CDN 不然的話還是把檔案放自己伺服器比較安全 因為很難保證這些CDN永遠不會出問題,或是有心搞事 而且這些JS CDN含有大量開源library 另外這些library的新舊版也同時存在 根本不可能去檢查完這些library都沒問題

還有這些CDN高機率有在做流量分析 等於是你網站的流量分析被白白撿走(免費CDN的代價?) 就算他們沒有植入額外的JS流量分析code 他們還是能用使用者ip做最基本的流量分析

真的還是要用的話建議避開這些頁面:

使用者登入頁面 管理員後台頁面 含有使用者個資隱私的頁面 (如果你的網站有在使用Google Analytics或是其他外部流量分析工具也是建議避開這些頁面,以確保網站的使用者隱私,還有外部廣告也不應該放在這些頁面)

例子:

https://www.inside.com.tw/article/4531

參考資料

本系列文參加 iT邦幫忙 的 2022鐵人賽
參賽主題： 這些那些你可能不知道我不知道的Web技術細節

comments powered by Disqus