權限與最小授權

最小權限原則

前面幾課的弱點都可能讓攻擊者以網站服務的身分讀取檔案或執行操作。服務本身擁有多少權限，決定了這些弱點的影響範圍。若服務以 root 執行，一個路徑穿越弱點就能讀取整台主機的檔案；若服務以專用帳號執行，能接觸的範圍僅限於這個帳號被授權的部分。

NIST 將最小權限（least privilege）定義為：系統應將使用者（或代表使用者的行程）的存取權限限制在完成指定工作所需的最小範圍。這項原則適用於帳號、服務、資料庫連線（第 7 課）與 API 權杖。

Linux 的檔案權限判斷規則如下：

1. 行程的有效使用者等於檔案擁有者時，使用第一組權限；否則，群組（含附加群組）相符時使用第二組；都不符合時使用第三組。只會使用其中一組
2. 路徑上的每一層目錄都需要搜尋權限 x
3. 在目錄內建立檔案需要該目錄的 w 與 x
4. 有效 UID 為 0 的行程（root）略過讀、寫與搜尋的檢查；執行一般檔案時，則要求至少一組權限含有 x

-rw-r----- root campusweb secret.env 這樣的表示方式，代表擁有者 root 可讀寫、群組 campusweb 可讀取、其他人沒有權限。

服務不應以 root 執行。 常見的理由是需要綁定 80 與 443 連接埠。常見的作法是由反向代理（例如 nginx）接收請求後轉給應用程式，應用程式以專用帳號執行；Linux 也提供 CAP_NET_BIND_SERVICE 這項能力（capability），可以只授予綁定低編號連接埠的權限。

本課的模擬環境。 下方的伺服器是模擬的，帳號與檔案皆為虛構，判斷結果由權限規則算出。權限管理只應在自己負責或獲得授權的系統上進行（第 1 課）。

SUID 與權限提升

一般情況下，程式以執行者的身分運作。SUID（set-user-ID）是例外：程式檔設有這個權限位元時，行程的有效使用者會變成檔案的擁有者。SUID 只改變有效使用者，行程的群組仍是執行者的。常見的用途是讓一般使用者透過特定程式執行需要較高權限的工作，例如修改自己的密碼。ls -l 顯示時，擁有者的執行位元會寫成 s：-rwsr-xr-x。Linux 會忽略腳本的 SUID 位元，它只對可執行的二進位檔有效。改變程式檔的擁有者或群組時，系統會清除 SUID 位元，需要重新設定。

這項機制的安全性完全取決於程式本身。擁有者為 root 的 SUID 程式若接受任意路徑或指令作為輸入，就相當於把 root 的部分權限交給所有能執行它的人。使用者由較低權限取得較高權限的情形，稱為權限提升（privilege escalation）。

系統管理上的原則如下：

• SUID 程式的數量盡量少，定期檢查清單，移除不需要的項目
• 若工作只需要讀取特定檔案，優先使用群組權限，不需要 SUID
• 確實需要時，讓程式由權限受限的專用帳號擁有，不使用 root，並限制哪些人可以執行
• 這類程式要嚴格驗證輸入，並在完成需要權限的動作後放棄權限

下方的練習用虛構的程式說明這個概念，不涉及任何真實程式的利用方式。

機密資訊的管理

資料庫密碼、API 權杖與簽章金鑰都屬於機密資訊。常見的外洩途徑是寫在程式碼裡並提交到版本控制，之後儲存庫被公開或被其他人複製。提交之後即使刪除，內容仍然保留在 Git 歷史中。

輪替（rotation）是定期更換機密資訊，讓被竊取的憑證只在短時間內有效。機密資訊本身也應遵守最小權限，每一組權杖只授予需要的範圍。

外洩後的處理順序。 OWASP 與 GitHub 的文件都指出，第一步是撤銷或輪替外洩的憑證。GitHub 也說明，憑證輪替後便無法再使用，可能已足以解決問題；重寫歷史有協作上的代價，內容也可能仍可在其他地方存取。

實務上還要注意服務的連續性。外洩的憑證原則上應立即撤銷。若服務支援新舊憑證並存，而且外洩範圍有限、沒有被使用的跡象，可以先建立新憑證並完成部署，再立刻停用舊憑證，以縮短中斷；儲存庫是公開的，或有跡象顯示憑證已被使用時，應立即撤銷，不等待部署完成。事後要檢查憑證是否被使用過（第 16、17 課）。

重點整理

• 最小權限將權限限制在完成工作所需的最小範圍，它不能消除弱點，但能限制影響範圍
• Linux 依擁有者、群組、其他的順序選用一組權限，路徑上的目錄都需要 x
• 服務應以專用帳號執行；檔案擁有者可以自行更改權限，服務不應擁有自己不該修改的檔案
• SUID 讓程式以檔案擁有者的身分執行，接受任意輸入的 SUID 程式會造成權限提升
• 機密資訊不寫進程式碼、不進版本控制；環境變數有其限制，優先使用機密管理服務
• 外洩時第一步是撤銷或輪替，重寫歷史無法讓憑證失效

下一課討論網路層：哪些資訊在網路上看得到，以及防火牆能做到與做不到的事。