強制門戶(Captive Portal)機制與OAuth白名單

存取網路認證這一塊有個俗稱「網頁認證」或者稱為「強制門戶」,為什麼要做強制門戶?因為這作法是不受系統平台拘束,只要有瀏覽器都就能進行身分驗證。設定簡單,使用簡單,所以是個廣泛使用的方式

根據《維基百科》,以下有三種常見的實現方式。

HTTP重定向

常見方法之一是將所有全球資訊網流量定向至網頁伺服器,同時向強制門戶返回HTTP重定向。當現代網際網路設備首次連接至網絡時,其將發出HTTP請求並期望返回HTTP 204狀態碼。若設備接收到HTTP 204狀態碼,則設備將認為自己擁有無限的網際網路訪問權限;若設備接收到HTTP 302狀態碼,則設備顯示強制門戶提示。

ICMP重定向

網關也可使用網絡層的網際網路控制消息協議重定向客戶端流量。

重定向DNS

當客戶端請求網際網路資源時,瀏覽器會查詢DNS。在強制門戶中,防火牆將確保僅有網絡DHCP伺服器提供的DNS可被未認證的客戶端使用(或將所有未認證客戶端的請求轉發至此DNS伺服器)。隨後,網絡提供的DNS伺服器將對所有的DNS查詢結果返回強制門戶頁面的IP位址。
強制門戶使用DNS劫持攻擊(與中間人攻擊類似)進行DNS重定向。為了減輕DNS投毒的影響,伺服器通常將存活時間設置為0。

最常見的就是第一種HTTP重定向,使用者可以看到瀏覽器上的url被改為強制門戶的url。這是因為收到回應來自強制門戶位置的HTTP 302狀態,HTTP 302狀態提示使用者需要進行強制門戶認證,而回應的位置也是強制門戶的URL,使用者瀏覽器就自然能切換到強制門戶網頁上。

透過開發人員工具,可以看到HTTP 302代碼
Response Headers Location為被Redirect後的URL

但在被Redirect之前,需要先有一個「HTTP請求」的動作,才能收到來自強制門戶的回應。因此只要設備一連上網路,就會先測試做個HTTP請求,來測試自己是否HTTP是不受限制的。

Windows10裝置一連上無線網路,就會DNS詢問「www.msftconnecttest.com」,然後測試自身HTTP存取權限是否受限。

因此可以知道是否當前的網路是否需要經過強制門戶才能得到網路存取權限,也就是自動跳通知提示要登入。

像Windows10是測試「www.msftconnecttest.com」,那其他平台也可能有自己的測試網址,透過DNS與錄封包可以抓到。總之,這些網址絕對不能放入白名單內,否則連線成功回傳HTTP 204,就不會觸發提示開啟瀏覽器登入與自動跳轉的功能。

如果要做強制門戶認證,那為什麼還要開其他的白名單呢?

因為要結合Oauth,我們需要連到相關網頁,例如微軟的Azure AD或是Google,帳密資訊與操作都在這些外部網站,因此勢必要開白名單才能順利完成Oauth。

白名單開太多,可能會造成提示登入與網頁跳轉功能失效,因此白名單要盡可能少開才行。

那要怎麼知道Oauth所需要開的Domain?上網搜尋相關白名單?這篇就是因為網路上找到的對應白名單不是太多就是有少,所以得好好了解到底過程中用到甚麼。

一般來說,白名單只會開放強制門戶的URL,因此就先只開放這個。設備連上線後,跳出強制門戶網頁,這時候打開「開發人員工具」,然後點入Oauth的按鈕,因為Oauth相關網頁不在白名單,過程會因此卡過。

透過開發人員工具,可以看到Oauth所有的Request URL

一個正常的網頁,上面的檔案要能正常被下載,然後到終端瀏覽器呈現。因此,在Oauth網頁檔案的Request URL,從中找到Domain,然後放入白名單內,反覆此流程,最終達到開最少白名單就能完成Oauth。

以下是測試出來的Azure AD Oauth所需要開的白名單

AzureAD_Oauth
login.microsoftonline.com
aadcdn.msftauth.net
login.live.com