iT邦幫忙

2022 iThome 鐵人賽

DAY 26
0
Modern Web

這些那些你可能不知道我不知道的Web技術細節系列 第 26

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

  • 分享至 

  • twitterImage
  •  

前言

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

服務器設置CSP相關回應頭

CSP,全名Content Security Policy,也就是內容安全政策。這是為了告訴瀏覽器,這個頁面允許什麼行為,讓瀏覽器幫忙在檢查一次。與設個相關的主要有兩個Response Headers:Content-Security-PolicyContent-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

參考資料

本文同時發表於我的隨筆


上一篇
你可能不知道的跨站腳本攻擊(Cross-Site Scripting,XSS)
下一篇
你可能不知道的CSS Injection
系列文
這些那些你可能不知道我不知道的Web技術細節33
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言