網站安全🔒 子網域與子目錄的選擇？從資安角度分析
筆者任職於 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下，給我一點鼓勵，若對資訊安全有興趣，也可以參考我的線上課程《經典駭客攻擊教程：給每個人的網站安全入門》
