內容安全政策 (Content Security Policy) 是甚麼？

阿恆

February 25, 2012

W3C 最近推出了「內容安全政策」(Content Security Policy, CSP) 的技術報告，建議在 HTTP 協定中加入一些新的標籤，希望可以令惡名照著的「跨網站攻擊程式」(cross site scripting, XSS) 永遠消失，至少令「儲存式」和「反射式」的 XSS 無法生存，至於「DOM 為本」的 XSS 可能仍需要開發人員繼續進行防禦。XSS 在 OWASP 的攻擊手段排名中名列第二，不少著名網站都曾受 XSS 攻擊，例如 Twitter、Facebook 等。究竟「內容安全政策」是甚麼？作為開發人員，對你有甚麼影響？

我不打算在這裏解釋 XSS 是甚麼，有興趣認識它的話可以到 OWASP 的網站閱讀詳細的解說和範例。

CSP 的特點

網站「白名單」

XSS 危險性高的其中一個原因是瀏覽器通常無條件地信任從伺服器收到的內容，即使內容已被第三者擅改，並從一個意想不到的網站加載額外內容。這正是 CSP 針對的弊病：CSP 容許開發人員宣告一個受信任的網站「白名單」，兼容 CSP 的瀏覽器只會從名單中的網站下載內容，名單以外的網站會被忽略。

不再容許插入式程式碼

XSS 其中一個作惡的方法是把程式碼插入到網站的內容，瀏覽器無法判斷收到的內容確實是網佔產生出來，還是被攻擊者動了手腳，添加了本來沒有的程式碼。針對這一點，CSP 強逼網站把內容和程式碼徹底分開，不能混合在一個檔案裏。這意味著從此你要把網頁內容中的程式碼全部移到外部檔案，對絕大部分的應用程式來說，無可避免要作修改，不過這是可以做到的，Twitter 就是一個高調地使用 CSP 的例子。

eval() 之死

另一個值得歡迎的功能是把部分 JavaScript 函式列入「黑名單」，主要是那些能夠從字符串創建程式碼的函式，例如 eval，從字符串創建程式碼是非常流行的攻擊技術，相當難以追查，因此取消所有這些函式實際上非常有用。

實作 CSP

要實作 CSP 可以從 HTTP header 或者 meta 標籤著手，W3C 推薦使用 HTTP header，以下就是一個例子：

1
2
3
4
Content-Security-Policy: default-src 'self';
img-src *;
object-src media1.example.com media2.example.com *.cdn.example.com;
script-src trustedscripts.example.com

它的意思如下：

第一行：預設的情況下，只允許從「self」即當前 URL 所代表的網站下載內容。

第二行：圖像可以從任何網站下載。

第三行：物件只能從指定名單的網站下載。

第四行：程式碼只能從指定的網站下載。

CSP 的現狀

現時 CSP 只是一份「技術報告」(technical report)，距離成為 W3C 的推薦標準 (recommended standard) 尚有一大段路，其間肯定會繼續演變和修改，不過現在幾乎所有瀏覽器都支援 CSP，Apache 也有外掛支援 CSP，所以配套已經非常齊備，我建議你下一個開發專案便使用 CSP，為你的客戶提供更好的保障。