網站安全🔒 子網域與子目錄的選擇?從資安角度分析
筆者任職於 Yahoo ,粉絲團:《程式猿吃香蕉🍌》 | 線上課程:《經典駭客攻擊教程:給每個人的網站安全入門》
子目錄與子網域的選擇?
對於網站設計時,子目錄 (sub directory) 與子網域 (subdomain)的選擇,大多著重在 SEO 以及系統架構的角度,某位學員在我的課程中問到如果以網站安全的角度,來看這兩者的不同,會是什麼樣呢?
我覺得十分有趣,因此將此篇內容彙整出來與大家分享。
別人是怎麼做的?
在進行分析之前,我們先看其他知名的網站是怎麼做的,我們可以看到 Uniqlo 的網站,它在切分不同國家別的時候,是採用切分子目錄 (sub directory)的方式來製作 (如下網站所示),我們以下統稱這種方式為「多子目錄」的實作方式:
* 台灣版的網站
* 日本版的網站
然而,以 Yahoo 的網站來說,它在切分不同國家別的時候,是採用切分子網域的方式來製作 (如下網站所示),我們以下統稱這種方式為「多子網域」的實作方式。
* 台灣版的網站
* 美國版的網站
我們可以說,這兩種方式都有人使用,並沒有絕對的對與錯,甚至幾乎所有的網站都是混合使用的情況,例如:
上面的例子中,既有「多子網域」的實作方式,區分 tw.mysite.com 以及 jp.mysite.com,又有「多子目錄」的實作方式,區分 /blog 以及 /profile。
然而,當我們在設計網站時,做出使用「多子目錄」或是「多子網域」這些決定並不是無意識的,而是取捨之後的結果,清楚地理解背後的影響總是比較好的,以下我將採用網站安全的角度來進行分析兩者做法的差異,分別考量以下這幾點:
- 同源政策 (Same Origin Policy)
- HTTPS 的設定
- Cookie 的送出
1. 同源政策 (Same Origin Policy) 的角度來看
若是採用「多子目錄」,根據 DOM 的同源政策,是不會使用 Path 來區分是否同源,因此無論是 /tw 或是 /jp 底下的 JavaScript 程式碼,都會被視為同源,既然是同源,他們就可以存取到同樣的 Cookie 。(不了解同源政策的朋友,可以參考我之前的文章:Same Origin Policy 同源政策 ! 一切安全的基礎)
我簡單做一個實驗,分別在這兩個網址:
透過 document.cookie 在 Chrome 開發者工具的 Console 頁籤,都可以取得不同 Path 的 Cookie,如下圖所示。
不管在上述的哪一個網址下執行 document.cookie ,都可以得到相同的結果,由上圖我們可以看到,在 Path 為「 / 」的 myCookie 以及在「 /hello 」底下的 myCookie ,都被讀取出來了。
如果你的網站採用「多子目錄」,只區分 Path ,沒有區分 Scheme, Domain, Port ,那麼你的網頁也會暴露在同樣的 Cookie 外洩風險之下。因為在 DOM 的同源政策下,並不會因為你區分了 Path ,而把 JavaScript 視為不同源。
舉例來說, 假設你的網站為:
一旦你的頁面有 XSS 漏洞,(不太清楚 XSS 的朋友,可以參考我的課程單元19 到單元 26),不論出漏洞的頁面是在 /tw 或是 /jp,一被駭客插入 JavaScript 程式碼,那麼不管是/tw 或是 /jp 底下的 Cookie 都會被偷走。
從同源政策的這個角度來看,採用「多子網域」的做法會比採用「多子目錄」來得安全一些。因為根據 DOM 的同源政策,不同子網域的 JavaScript 會被視為不同源,無法存取不同網域 ( domain ) 底下的 Cookie。
舉例來說,假設你的網站改為:
因為 DOM 的同源政策限制,tw.mysite.com 底下的 JavaScript 無法存取 jp.mysite.com 底下的 Cookie,也就是說,當 tw.mysite.com 有 XSS 漏洞的時候,不會影響到 jp.mysite.com 底下的 Cookie。
因此你在做網站規劃的時候,可以根據同源政策,考量 Cookie 存取的安全性,來選擇要採用「多子網域」的做法或是「多子目錄」的做法。
2. HTTPS 的設定
以現代 (Modern) 的網站來說,HTTPS 的設定已經是最基本要求的安全設定了,關於 HTTPS 的設定,通常針對不同網域有不同的憑證。 採用「多子目錄」的話,/tw 和 /jp 因為網域一樣,所以會使用同一張憑證,比較方便更新。採用「多子網域」的話,也有 Wildcard SSL 的方案可以使用,透過同一張憑證來保護不同子網域的網站。 在 HTTPS 的設定上,並沒有特別的差異。
3. Cookie 的送出
根據我在前一篇文章介紹的安全設計原則:最小權限原則,有些人會在意,如果那個網路服務不需要收某個 Cookie ,就不要傳遞某個 Cookie 出去給它,舉例來說,我們的圖片網址,其網域通常會是另一個網域 (例如:Yahoo 網站的圖片會改放在 yimg.com 這個網域),因為我們存取圖片時,通常使用的 Cookie 是另外一組 Cookie。透過區分 Domain 的方式,讓正常瀏覽的網頁(例如:yahoo.com) 的 Cookie 不要被送出。或是,有一些不需要 Cookie 的網路服務,也會切不同的 Domain,這種做法又稱為 Cookie Free。
由上述的例子我們可以知道, Cookie 的送出對於網站安全性是有影響的。
根據 Cookie 的同源政策,「多子目錄」的作法,因為 Path 不同,所以送出 Cookie 時會有所區分。(不了解 Cookie 同源政策的朋友,可以參考我之前的文章:Same Origin Policy 同源政策 ! 一切安全的基礎)
舉例來說, 假設你的網站為:
使用者造訪 /tw 和 /jp 時會有不同的 Cookie 被送出。簡單來說,設定在 /tw 底下的 Cookie 不會被瀏覽器送到 /jp 去,反之亦然,符合最小權限原則。
採用「多子網域」的作法,因為 Domain 不同,所以在送出 Cookie 時,也會有不同的 Cookie 被送出。
舉例來說,假設你的網站改為:
使用者造訪 tw.mysite.com 和 jp.mysite.com 時,會有不同的 Cookie 被送出,因為根據 Cookie 的同源政策,歸在不同 Domain 底下的 Cookie 會被視為不同源,設定在 tw.mysite.com 底下的 Cookie 不會被瀏覽器送到 jp.mysite.com 去,反之亦然,符合最小權限原則。
因此,以 Cookie 送出的觀點來看,「多子目錄」和「多子網域」並沒有特別的差異,但如果加上考量 Cookie 被存取的安全性,根據第一點我們討論的 同源政策觀點,「多子網域」方案會安全一些。
以上,便是我從網站安全的角度,分析子網域與子目錄的選擇,大家之後在設計網站架構時,可以從這些角度進行思考,希望對大家有幫助 :)
若是喜歡我分享的內容,歡迎幫我按個拍手,可拍 50下,給我一點鼓勵,若對資訊安全有興趣,也可以參考我的線上課程《經典駭客攻擊教程:給每個人的網站安全入門》