別擔心，我們在 PowerShell 裡手動強制開啟 TLS 1.2 ，就可以輕鬆搞定。

絕招一：強制開啟 TLS 1.2 下載法

請複製以下這段程式碼，整段直接貼進你的 PowerShell 視窗裡面執行：

PowerShell

# 1. 強制讓 PowerShell 使用 TLS 1.2 加密協定
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# 2. 重新嘗試下載安裝檔
Invoke-WebRequest -Uri "https://github.com/microsoft/go-sqlcmd/releases/latest/download/sqlcmd-windows-amd64.msi" -OutFile "$env:USERPROFILE\Downloads\sqlcmd.msi"

# 3. 執行安裝
Start-Process msiexec.exe -ArgumentList "/i `"$env:USERPROFILE\Downloads\sqlcmd.msi`"" -Wait

執行之後，畫面上應該會彈出上面的截圖。

絕招二：繞過 IE 增強式安全性封鎖

如果用了第一招還是失敗，甚至跳出討人厭的 Internet Explorer 紅色警告，那就代表你抓到幕後黑手了！這是 Windows Server 惡名昭彰的「 IE 增強式安全性設定（ IE ESC ）」在作怪。

因為 PowerShell 在下載檔案的時候，背後會偷偷調用 Internet Explorer 的核心元件，而 Server 的安全機制預設會把外面所有的網站（ 包括 GitHub ）通通鎖死，當成大魔王在防防禦。

既然系統的安全性指令一直擋路，我們就改用「 全指令、不調用 IE 網頁核心 」的方法來下載，直接繞過這個煩人的限制。

請在 PowerShell 中執行這段全新的指令：

PowerShell

# 1. 強制開啟 TLS 1.2
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# 2. 使用微軟官方下載中心（保證存在的 x64 穩定版網址）
$webClient = New-Object System.Net.WebClient
$url = "https://go.microsoft.com/fwlink/?linkid=2142258"
$output = "$env:USERPROFILE\Downloads\MsSqlCmdLnUtils.msi"
$webClient.DownloadFile($url, $output)

# 3. 執行安裝
Start-Process msiexec.exe -ArgumentList "/i `"$output`"" -Wait

這次執行完之後，畫面就不會再跳出那些紅色的警告。它會非常低調、靜悄悄地下載完成，接著直接彈出 sqlcmd 的安裝視窗。你同樣只要動動手指，跟著點下一步完成安裝即可。

最後再次提醒，安裝完畢後，一樣要關掉並重新打開一個新的 PowerShell 或 cmd 視窗，系統的環境變數才會生效。

大家在網站或手機 App 登入帳號時，有沒有想過，你的密碼和資料是怎麼在網路世界裡安全傳遞的？今天我們要來聊聊一個保護你我隱私的幕後功臣，它的名字叫 PKCE。

PKCE 全名是 Proof Key for Code Exchange，大家通常把它讀作 Pixie（就是小精靈的那個英文發音）。它是 OAuth 2.0 這個登入標準機制的安全擴充功能。簡單來說，它就像是幫你的行動 App 或單頁式網頁應用程式（SPA）請了一位動態保鏢，專門防止壞人中途攔截你的登入憑證。

PKCE 是如何運作的？

傳統的登入方式需要一組固定的秘密鑰匙（Client Secret），但如果把這把鑰匙藏在手機 App 或前端網頁裡，很容易就被厲害的駭客挖出來。 PKCE 的聰明之處，就在於它每次登入都用「臨時隨機抽樣」的方式，流程主要分為四個步驟：

1. 產生驗證碼： 你的手機 App 或網頁會在本地端隨機亂數產生一組高密度的字串，這組密碼學字串叫做 code_verifier。
2. 生成挑戰碼： 接下來，系統會把這組字串拿去進行雜湊運算（通常是 SHA-256 演算法），再經過編碼轉換成另一組字串，叫做 code_challenge。
3. 發送請求： 你的 App 會把這組挑戰碼和運算方法，一起送到官方的授權伺服器，大喊一聲「我要登入！」
4. 驗證與核發： 當 App 拿到授權碼，準備跟伺服器換取真正能通行的 Token 時，必須交出第一步產生的原始驗證碼。伺服器會在後端用同樣的方法算一次，確認跟當初的挑戰碼一模一樣，才會點頭放行。

為什麼我們需要 PKCE ？

如果沒有 PKCE 的保護，當授權碼在網路跳轉回傳的途中，很容易被惡意軟體或中間人側錄攔截。駭客只要偷到這個授權碼，就能假冒你的身份去跟伺服器換取存取權限。

網頁後端伺服器因為躲在暗處，可以安全地藏好秘密鑰匙，但手機 App 是公開在外的客戶端，根本沒辦法安全地藏東西。 PKCE 透過每一次登入時「動態出題、動態對答案」的機制，確保發起請求和最後拿 Token 的是同一個合法的 App。這樣一來，壞人就算在半路偷到授權碼，沒有原始的驗證碼也只能乾瞪眼，完全無法盜用！

工程師的私房補丁日誌： AppScan 安全漏洞大作戰

看完了上面的小精靈防護機制，順便來瞧瞧我們這次為了應付 AppScan 安全檢查，在後端默默做了哪些升級。這絕對不是在敷衍檢查，這是為了愛與和平。

核心變更項目

關於 PKCE 漏洞修補，我們擴充了 OAuthProvider 介面，新增了 Supports PKCE() bool 與 Exchange(…oauth2.AuthCodeOption) 功能。現在 Entra ID 會乖乖回傳 true ，而交大 NYCU 則會回傳 false 。登入處理器會自動產生一組驗證碼並發送 S256 挑戰碼，回呼處理器則會負責把驗證碼傳給 Exchange 進行核對。

關於 Cookie 檔安全，我們在前一次的提交中，就已經把驗證 Cookie 檔通通綁上 SameSite=Strict 機制了。

關於 API 安全標頭，我們加入了 AddAPISecurityHeaders 中介軟體，強制執行以下防禦：

• Cross-Origin-Resource-Policy 設為 same-origin
• Strict-Transport-Security 設為 max-age=31536000; includeSubDomains
• Cache-Control 設為 no-store 搭配 Pragma 設為 no-cache
• Referrer-Policy 設為 strict-origin-when-cross-origin

AppScan 漏洞修補成績單

以下是這次的戰果，我們把所有紅字都變成綠色的勾勾了。

• OAuth Implicit Grant 缺 PKCE 漏洞： 中級風險，修復狀態為已完成。
• Cookie 的 SameSite 設定不當： 中級風險，修復狀態為已完成。
• API 缺少 CORP 標頭： 中級風險，修復狀態為已完成。
• 可快取的 SSL 網頁： 低級風險，修復狀態為已完成，透過 Cache-Control 防禦。
• 缺少 Referrer-Policy 標頭： 低級風險，修復狀態為已完成。
• 缺少 HSTS 標頭： 低級風險，修復狀態為已完成。

Addresses AppScan security findings for the backend.

Changes

• PKCE (OAuth Implicit Grant flaw): OAuthProvider interface extended with SupportsPKCE() bool and Exchange(…oauth2.AuthCodeOption). Entra ID returns rue; NYCU returns alse. Login handler generates a verifier and sends S256 challenge; Callback handler passes verifier to Exchange.
• SameSite=Strict: Auth cookies already fixed in previous commit (SameSiteStrictMode).
• API Security Headers (AddAPISecurityHeaders middleware):
  • Cross-Origin-Resource-Policy: same-origin
  • Strict-Transport-Security: max-age=31536000; includeSubDomains
  • Cache-Control: no-store + Pragma: no-cache
  • Referrer-Policy: strict-origin-when-cross-origin

AppScan Findings Addressed

Finding	Severity	Status
OAuth Implicit Grant (missing PKCE)	M	Fixed
Cookie SameSite improper	M	Fixed
CORP header missing on API	M	Fixed
Cacheable SSL pages	L	Fixed (Cache-Control: no-store)
Missing Referrer-Policy	L	Fixed
Missing HSTS	L	Fixed

要讓 ＯＷＡＳＰ ＺＡＰ 成功掃描登入後的管理介面，最關鍵的任務就是讓 ＺＡＰ 掌握身分驗證機制，不然它爬到一半被系統踢登出，掃描就等於白做了。

在 Ｄｏｃｋｅｒ 環境中執行 ＺＡＰ，主要有兩種方式，一種是透過瀏覽器操作圖形介面，另一種是直接用指令跑自動化掃描。既然需要設定登入資訊這麼複雜的操作，強烈建議使用第一種圖形介面，操作起來就跟在本機裝軟體一模一樣。

以下是完整的設定與執行步驟。

方法一：啟動 Web Swing 圖形介面（推薦，方便設定登入）

Docker 版本的 ZAP 內建了 Web Swing 功能，可以把 GUI 畫面渲染到網頁上。

1. 執行 Docker 指令

打開你的終端機（Terminal 或 PowerShell），輸入以下指令：

Bash

docker run -u zap -p 8080:8080 -p 8090:8090 -i owasp/zap2twig:latest zap-webswing.sh

參數解析：

• -p 8080:8080：ZAP Web 界面的連接埠（透過瀏覽器訪問）。
• -p 8090:8090：ZAP 本身的 Proxy 連接埠。
• owasp/zap2twig:latest：這是包含完整週邊工具的 ZAP 映像檔。

2. 開啟瀏覽器操作

指令跑起來後，打開你本機的瀏覽器，輸入以下網址：

http://localhost:8080/zap/

你就會在網頁裡看到完整的 ZAP 操作視窗。接下來，你就可以按照前面教的步驟去設定 Context、Authentication 和 Users。

方法二：使用命令列 (CLI) 進行自動化掃描

如果你已經把登入的設定檔匯出成 .context 檔案，或者管理介面可以單靠 Token 驗證，你也可以直接用指令讓 Docker 裡的 ZAP 跑完就結束。

執行 Baseline Scan（基本弱點掃描）指令：

Bash

docker run -t owasp/zap2twig:latest zap-baseline.py -t https://your-target-site.com

Docker 環境下的關鍵注意事項（非常重要）

當 ZAP 住在 Docker 容器裡時，有兩個常見的「坑」需要注意：

1. 目標網站也在你的本機 (Localhost) 嗎？

如果你的管理介面網站也是用 Docker 跑在本機，或是跑在本機的 http://localhost:3000：

• 不能在 ZAP 裡面填 localhost，因為對 ZAP 容器來說，localhost 指的是 ZAP 自己。
• 解決方法：將網址改為 http://host.docker.internal:3000/，這樣 ZAP 才能穿透容器存取到你本機的服務。

2. 資料如何儲存與匯出？

Docker 容器一旦關閉，裡面的設定和掃描報告就會消失。如果你想把掃描報告存回本機電腦，必須掛載資料夾（Volume）：

Bash

# 在指令中加入 -v 參數，將本機的資料夾與容器內同步
docker run -u zap -v /path/to/your/local/dir:/home/zap/reports:rw -p 8080:8080 -i owasp/zap2twig:latest zap-webswing.sh

你的管理介面網站目前是部署在雲端測試機，還是也同樣跑在你的本機 Docker 環境中呢？

要讓 OWASP ZAMP (Zed Attack Proxy) 成功掃描「登入後」的管理介面，核心關鍵在於讓 ZAP 掌握身分驗證（Authentication）機制，這樣它才不會在掃描到一半時因 Session 過期而被踢登出。

以下是實現這個目標最完整、最推崇的設定流程：

步驟一：使用 Context（上下文）鎖定目標

1. 打開 ZAP，在左側的 Sites 樹狀目錄中，找到你的網站。
2. 右鍵點擊網站根目錄 -> Include in Context -> 選擇 New Context（或預設的 Default Context）。
3. 這會打開 Context 設定視窗。在 In Scope 頁面中，確保你的網站 URL 已被勾選。

步驟二：錄製登入步驟並設定登入指標

ZAP 需要知道「怎麼登入」以及「怎麼判斷目前是登入還是登出狀態」。

1. 錄製登入請求

• 建議使用 ZAP 內建的瀏覽器（點擊右上角的瀏覽器圖示，如 Chrome/Firefox）手動操作一次登入。
• 登入成功後，回到 ZAP 的 History 標籤頁。
• 找到那筆發送帳號密碼的 POST 請求（通常是 /login 或 /auth）。
• 右鍵點擊該請求 -> Flag as Context -> 選擇你的 Context -> Form-based Auth Login Request。

2. 設定登出指標（Logged Out Indicator）

ZAP 在掃描時如果看到特定的字眼，就知道自己被踢登出了（必須重新登入）。

• 在剛剛內建瀏覽器的畫面上，找到「登出後才會出現的文字」（例如：請先登入、Login、帳號或密碼錯誤）。
• 在 ZAP 的 Context 設定視窗中，切換到 Authentication 頁面。
• 將驗證方法改為 Form-based Authentication（如果剛剛有正確 Flag，這裡會自動帶入登入 URL 和參數）。
• 在下方 Logged Out Indicator 欄位中，填入剛剛找到的登出關鍵字（支援正則表達式，例如：.*請先登入.*）。

步驟三：設定使用者憑證（Users）

讓 ZAP 知道要用哪組帳密去登入管理介面。

1. 在 Context 設定視窗中，點選 Users 頁面。
2. 點擊 Add 新增一個使用者（例如：admin）。
3. 勾選 Enabled，並輸入管理員的 Username 與 Password。

步驟四：設定強制使用者模式（Forced User Mode）

這是最關鍵的一步，強迫 ZAP 的所有掃描工具（包含 Spider 和 Active Scan）都帶著這個身分去跑。

1. 在 Context 設定視窗中，點選 Forced User 頁面。
2. 在下拉選單中，選擇你剛剛在 步驟三 建立的那個使用者（admin）。
3. 點擊 OK 儲存並關閉 Context 設定視窗。
4. 啟用強制模式：在 ZAP 主介面上方的工具列，找到一個「鎖頭搭配一個小人」的圖示（Forced User Mode），把它點擊下去（讓它呈現鎖定/啟用的狀態）。

步驟五：開始安全掃描

現在 ZAP 已經具備自動登入的能力了，你可以開始掃描管理介面：

1. Spider（蜘蛛爬蟲）：
   • 在左側 Sites 樹狀目錄，右鍵點擊管理介面的資料夾（例如 /admin）。
   • 選擇 Attack -> Spider…。
   • 在彈出的視窗中，User 欄位記得選擇你設定的 admin，然後點擊 Start Scan。這時 ZAP 就會帶著登入身分去爬取所有管理員才能看到的頁面。
2. Active Scan（主動掃描/弱點掃描）：
   • 爬蟲結束後，一樣右鍵點擊該目錄 -> Attack -> Active Scan…。
   • 同樣確保 User 選擇 admin，點擊 Start Scan，ZAP 就會開始對管理介面進行漏洞狂轟猛炸。

進階小撇步 (如果管理介面有驗證碼/雙因子認證 CAPTCHA / 2FA)：

自動化工具通常無法破解驗證碼。如果遇到這種情況，建議改用 Replacer 功能 或 Scripting 直接把手動登入後取得的 Cookie 或 Bearer Token 塞給 ZAP 瀏覽器，但缺點是 Token 過期就必須手動更新。

你在設定 Form-based Auth 的過程中，有遇到特定的登入阻礙（例如前端加密、Token 驗證）嗎？

GUI 很麻煩, 改用 terminal 比較方便

Shell Tail second dry-run log 35 lines
Found Java version 17.0.19
Available memory: 15863 MB
Using JVM args: -Xmx3965m
307 [main] INFO org.parosproxy.paros.Constant – Copying default configuration to /home/zap/.ZAP/config.xml
381 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/session
382 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/dirbuster
382 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/fuzzers
383 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/plugin
Jul 06, 2026 3:33:16 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
Downloading add-on from:
https://github.com/zaproxy/zap-extensions/releases/download/commonlib-v1.42.0/commonlib-release-1.42.0.zap
Downloading add-on from:
https://github.com/zaproxy/zap-extensions/releases/download/authhelper-v0.40.0/authhelper-beta-0.40.0.zap
Downloading add-on from:
https://github.com/zaproxy/zap-extensions/releases/download/selenium-v15.51.0/selenium-release-15.51.0.zap
Add-on downloaded to: /home/zap/.ZAP/plugin/authhelper-beta-0.40.0.zap
Add-on downloaded to: /home/zap/.ZAP/plugin/commonlib-release-1.42.0.zap
Add-on downloaded to: /home/zap/.ZAP/plugin/selenium-release-15.51.0.zap

Tasks
—
│ │ Subagents
│ No subagents
│
│ Shell Commands
│ ❯ ◎ Run ZAP full scan in background, logging output [detached background]

改用 AI 代勞進行 scan 超方便, 完全不需要去學習如何使用.

嗨，各位路過的探險家！今天來聊聊我們網站的超級門神 ── WAF 防火牆。

這個系統就像是一個戒備森嚴的城堡，為了不讓壞人進來搗亂，門神阿福手上有一張點名簿，也就是所謂的白名單。只要你的 IP 位址不在這張點名簿上，阿福就會直接把你塞進小黑屋，連大門口都進不來。

最厲害的是，阿福非常有個性，他只保護特定的城堡。就算隔壁的系統不小心被圍攻，我們 Project Name 這邊依然穩如泰山。

阿福的點名簿現況

目前只有拿到特別通行證的網段才能順利通行：

• 某神秘機房專區： 192.168.1.0/24
• 核心團隊的秘密基地： 192.168.2.0/24
• 測試專用通道： 192.168.3.0/24
• 管理員的個人特權 IP： 203.0.113.89

前置作業：請出管理員鑰匙

在指揮阿福修改點名簿之前，請先確認你已經切換到正確的管理帳號，不然阿福是絕對不會理你的。

指令如下：

az account set –subscription “請輸入你的雲端帳號萬用鑰匙代碼”

新增特權 IP 的四大步驟

假設今天有兩組好朋友，一組是 192.168.99.0/24 的新同學，另一組是 198.51.100.6 的外包夥伴，想要加入點名簿。請跟著以下步驟做：

步驟 1：偷看目前的點名簿

先把阿福現在手上到底登記了誰調查清楚。

az network application-gateway waf-policy custom-rule show –policy-name 門神名稱 –resource-group 城堡名稱 –name 規則名稱 –query “matchConditions[0].matchValues” -o json

步驟 2：大家排排站，準備新名單

請把剛剛查出來的舊名單複製出來，然後把新朋友的名字加進去，排成一列。

步驟 3：大手一揮，整張蓋過去

超級重要： 阿福很健忘，你不能只跟他說我要加兩個人，你要給他一張全新的完整名單，否則舊的人會被他通通忘光光。

我們會用一個腳本把新舊名單綁在一起，然後直接覆蓋：

$allIPs = @(

“192.168.1.0/24”,

“192.168.2.0/24”,

“192.168.3.0/24”,

“203.0.113.89”,

“192.168.99.0/24”, # 這是新朋友一號

“198.51.100.6” # 這是新朋友二號

)

（接下來把這串名單打包成 JSON 格式後，用雲端指令送給阿福更新。因為指令比較長，這裡就不贅述，重點是名單要帶齊。）

步驟 4：檢查阿福有沒有認真工作

更新完之後，再次叫阿福把名單拿出來核對，看看剛才加的新朋友是不是都在上面了。

如果想踢掉某個 IP 呢

方法完全一樣。先去步驟 1 看名單，在步驟 2 的時候拿橡皮擦把不想看到的人擦掉，最後用步驟 3 的覆蓋大法，這個人就被阿福除名了。

實地測試：看看阿福有沒有偷懶

名單改完之後，我們一定要來測試看看阿福是不是真的有在認真抓壞人：

• 叫沒拿通行證的朋友點網址： 如果畫面跳出 403 錯誤，代表被阿福成功攔截，阿福好棒。
• 自己人從白名單點網址： 如果正常顯示網頁，代表通行無阻。

筆記小重點

• 隔壁鄰居很安全： 這個點名簿設定只針對我們 Project Name ，完全不會影響到同一個伺服器底下的其他系統。
• 覆蓋完請稍等： 阿福收到新名單後，大概需要 1 到 2 分鐘的時間來認熟面孔，請給他一點時間。
• 附贈隱形護盾： 除了不讓陌生人進來，阿福同時還開啟了國際防禦標準，一般的網路流氓就算換了白名單 IP 進來，只要手腳不乾淨一樣會被抓走喔。

如果你想使用 Azure Portal 網頁畫面來操作，步驟非常直覺，請跟著以下步驟點選。

第一步、登入與尋找策略

首先打開瀏覽器登入 Azure Portal 網站。在網頁最上方的搜尋欄輸入 Web Application Firewall policies 或是 WAF 策略，然後點選進入。

第二步、選擇特定的策略

在列表中找到並點選你正在使用的 WAF 策略名稱。

第三步、進入自訂規則

進入該策略的頁面後，查看左側的選單，在設定區塊中，點選自訂規則。

第四步、修改名單

在自訂規則的列表中，點選你用來管制 IP 的那一條規則。點開之後，你會看到比對條件，找到比對變數為 RemoteAddr 的那一項，你就可以直接在下方的數值列表中，新增或刪除你要異動的 IP 位址。

第五步、儲存更新

修改完成後，點選畫面最上方的儲存按鈕。系統大約需要 1 到 2 分鐘的時間將新名單同步到防火牆。

在 Azure 的網路安全性群組（NSG）世界裡，有時候我們會遇到一個很像「既要又要」的邊緣狀況：你想要同時把好幾個 Port 關起來，不讓壞人進來，但同時又希望特定幾位好朋友（白名單 IP）可以大搖大擺地走進去。

要同時做到阻擋大家又放行自己人，最乾淨也最聰明的作法，就是利用兩條規則的「優先順序（Priority）」差來玩一場網路版的邏輯遊戲。

因為 Azure NSG 這個門神在檢查規則時，是採取「由上到下」比對的。數字越小的規則越優先執行，而且只要一比對成功，它就會直接定案，懶得再看下面的規則了。

核心邏輯大公開

簡單來說，你只需要左右開弓，建立以下兩條規則：

重要提醒：允許（Allow）規則的 Priority 數字（例如 300）必須小於阻擋（Deny）規則的 Priority 數字（例如 301）。如果把阻擋數字寫得太小，門神就會先把大家都趕走，你的好朋友就再也進不來了。

詳細設定步驟（Azure Portal 傳送門操作）

請直接移駕到你的 NSG （azure vmptstgjpe001-nsg）的「輸入安全性規則（Inbound security rules）」頁面，深呼吸之後點選「新增（Add）」：

步驟 1：建立白名單允許規則

1. Source（來源）：下拉選單請選 IP Addresses。
2. Source IP addresses（來源 IP 位址）：輸入你想放行的白名單 IP。如果好朋友有點多，可以用半形逗號隔開，例如： 1.1.1.1, 2.2.2.0/24。
3. Source port ranges（來源連接埠範圍）：維持預設的 * 號就好。
4. Destination（目的地）：選 Any 或是直接指定那一台 VM 的內網 IP。
5. Destination port ranges（目的連接埠範圍）：輸入你想控制的多個 Port，中間記得用半形逗號隔開，例如： 80, 443, 8080。
6. Protocol（通訊協定）：看你心情與需求，選 TCP、UDP 或是 Any。
7. Action（動作）：大方地選擇 Allow。
8. Priority（優先順序）：給它一個比較小的數字，例如 300。
9. Name（名稱）：取一個好辨識的名字，像是 Allow_Whitelist_MultiPorts。

步驟 2：建立其餘全部阻擋規則

再次點選「新增（Add）」來建立第二道關卡：

1. Source（來源）：這次要選 Any，代表任何路人甲乙丙。
2. Source port ranges：一樣維持 * 號。
3. Destination：選 Any。
4. Destination port ranges：請輸入與步驟 1 完全一模一樣的多個 Port，例如： 80, 443, 8080。
5. Protocol：請與步驟 1 保持同步。
6. Action（動作）：這次要狠下心選擇 Deny。
7. Priority（優先順序）：數字必須比步驟 1 還要大，例如 301。
8. Name（名稱）：給它一個威武的名字，像是 Deny_All_MultiPorts。

進階管理小技巧

如果你的白名單 IP 常常像天氣一樣變來變去，或者你手底下的 VM 越來越多，每次都要手動來改 NSG 規則真的會讓人想砸鍵盤。

這時候建議可以利用「應用程式安全性群組（Application Security Group, ASG）」或者 Azure 的「IP Groups」功能。這就像是把所有好朋友的名字直接打包進一個群組懶人包，以後 NSG 規則的來源直接指定這個群組就可以了，管理起來輕鬆到可以提早下班！

以下為你整理出最流暢的申請 4 大步驟：

第一步：建立新專案

1. 前往 Google Cloud Console。
2. 登入你的 Google 帳號。
3. 點擊左上角的專案下拉選單，選擇 「新建專案」 (New Project)。
4. 輸入專案名稱（例如：MyAwesomeApp），然後點擊 「建立」。

第二步：設定 OAuth 同意畫面 (OAuth Consent Screen)

這是使用者在登入你的 App 時會看到的授權畫面，必須先設定它。

1. 點擊左側選單的 「API 和服務」 > 「OAuth 同意畫面」。
2. 選擇 User Type：
   • 外部 (External)： 開放給所有 Google 帳號（一般應用程式選這個）。
   • 內部 (Internal)： 僅限你 Google Workspace 組織內的成員（企業內部工具選這個）。
3. 填寫基本資料：應用程式名稱、使用者支援電子郵件 以及 開發人員聯絡資訊，完成後點擊「儲存並繼續」。
4. 範圍 (Scopes)： 設定你想拿到的權限（如 email, profile）。初次測試可以先不選，直接跳過。
5. 測試使用者 (Test Users)： 如果你的專案還在「測試中」階段，必須在這裡新增你自己的測試 Email，否則其他帳號會無法登入。

第三步：建立憑證 (Credentials) 取得密鑰

這一步會生成你的 Client ID 和 Client Secret。

1. 點擊左側選單的 「憑證」 (Credentials)。
2. 點擊上方的 「+ 建立憑證」 > 「OAuth 用戶端 ID」。
3. 選擇你的 應用程式類型（例如：網頁應用程式、Android、iOS 等）。
4. 填寫核心網址（以網頁應用程式為例）：
   • 已授權的 JavaScript 來源： 你的網站首頁（例如：http://localhost:3000 或 https://yourdomain.com）。
   • 已授權的重新導向 URI： 使用者登入成功後，Google 把 Code 送回你網站的後端路由（例如：http://localhost:3000/auth/google/callback）。※ 注意：這裡一定要設定精準，否則會噴 redirect_uri_mismatch 錯誤。
5. 點擊 「建立」。

恭喜！ 畫面上會跳出你的 用戶端 ID (Client ID) 和 用戶端密鑰 (Client Secret)。請立刻複製並妥善保管，密鑰絕對不能外流！

第四步：切換為「生產模式」（選填）

在開發測試階段，你的專案狀態會是「測試中 (Testing)」，只有你在第二步設定的測試小夥伴能登入，且可能會有不安全應用的警告。

• 當你的 App 準備好上線時，回到 「OAuth 同意畫面」，點擊 「發布應用程式」 (Publish App) 切換為正式生產模式。
• 備註：如果你申請了敏感權限（如讀取使用者的 Gmail 私訊），Google 會需要人工審查，可能需要幾天到幾週的時間。

我有測試環境 domain name 與正式環境 domain name 要申請2組 OAuth 2.0 用戶端 ID 嗎? 還是同一組ID即可。

建議申請「2 組獨立的 OAuth 2.0 用戶端 ID (Client ID)」。

雖然在技術上，Google 允許你在同一組 Client ID 的「已授權的重新導向 URI」中，同時填入測試環境與正式環境的網址，但非常強烈建議分開申請。原因如下：

1. 安全性考量（最重要的原因）

• 憑證外流風險： 測試環境通常防護較弱，可能會有較多開發人員、測試人員接觸到設定檔。如果測試環境的 Client Secret（用戶端密鑰）不小心外流，且你兩邊用同一組 ID，攻擊者就能利用外流的密鑰去染指或偽造正式環境的登入請求。
• 網址白名單污染： 萬一測試環境網址被惡意劫持或存在漏洞，它與正式環境共享同一個 OAuth 信任圈，會帶來額外的安全隱患。

2. Google 審查與「發布狀態」限制

Google Cloud 專案的 OAuth 同意畫面有分兩種狀態：

• 測試中 (Testing)： 只有白名單內的「測試使用者」可以登入，且登入時會跳出「未經驗證的應用程式」警告。
• 生產模式 (In Production)： 開放給所有 Google 帳號登入。如果使用了敏感權限（Scopes），還需要通過 Google 的人工驗證。

如果你只用一組：

當你的專案為了正式環境切換成「生產模式」並送交審查時，如果你的網址白名單裡還夾帶了 project-name.test.example.com.tw（而且通常測試環境在外網無法被 Google 審查官順利連上），這可能會導致你的 Google 審查被拒絕 (Rejected)，因為 Google 要求生產模式下的網址必須是公開、真實且符合規範的。

最佳實作做法 (Best Practice)

為了架構清晰與安全，你可以選擇以下兩種配置方式：

方案 A：在同一個 Google Cloud 專案下，建立 2 個 Client ID（推薦，最方便）

在同一個專案的「憑證」頁面中，點擊兩次「建立憑證 > OAuth 用戶端 ID」：

• 第一組 ID（命名：Project Name – Test）：
  • 重新導向 URI 填：https://projectname.test.example.com.tw/oauth2/callback
• 第二組 ID（命名：Project Name – Prod）：
  • 重新導向 URI 填：https://projectname.example.com.tw/oauth2/callback

這樣你在程式碼的環境變數（.env）中，測試機就讀取測試的 ID/Secret，正式機就讀取正式的 ID/Secret，彼此互不干擾。

方案 B：建立 2 個獨立的 Google Cloud 專案（最嚴謹）

• 專案一：PorjectName-Test（專案狀態保持在 Testing，方便開發隨時測試）
• 專案二：PorjectName-Prod（專案狀態切換為 Production，專門用來跑正式上線與 Google 審查流程）

總結： 為了維護系統的安全防線與後續維護的便利性，請務必為測試與正式環境分開申請獨立的憑證！

應用程式是哪種類型, Vue 3 + Vite

既然你的前端技術棧是 Vue 3 + Vite，在架構設計上你首先需要釐清一個關鍵問題：你的應用程式有沒有後端（Backend，如 Node.js, Python, Go）？

這會直接決定你如何實作 Google OAuth。以下為你說明這兩種情境與實作方式：

情境一：有後端（推薦，最安全）

這是最正統的做法。Vue 3 只負責顯示「登入按鈕」，使用者點擊後會引導到 Google 登入，登入成功後 Google 會把驗證碼（Authorization Code）傳給你的後端，由後端去跟 Google 交換 Token，並簽發你網站自己的 JWT 給 Vue 3。

在這種模式下，你的 OAuth 2.0 用戶端 ID 類型要選擇：「網頁應用程式」 (Web Application)。

Vite / Vue 3 前端實作步驟：

目前社群上最推崇、封裝最完整的套件是 vue3-google-signin。

安裝套件：Bash

npm install vue3-google-signin

在 main.js 或 main.ts 中初始化：

import { createApp } from 'vue'
import App from './App.vue'
import GoogleSignInPlugin from 'vue3-google-signin'

const app = createApp(App)

app.use(GoogleSignInPlugin, {
  // Vite 的環境變數必須以 VITE_ 開頭
  clientId: import.meta.env.VITE_GOOGLE_CLIENT_ID,
})

app.mount('#app')

在畫面上建立登入按鈕 (Login.vue)：

<script setup>
import { GoogleLogin } from 'vue3-google-signin'

const handleLoginSuccess = (response) => {
  // 這裡會拿到 Google 回傳的 code 或 credential
  console.log("Google 登入成功:", response);

  // 【關鍵】將這個 response (含 code) 用 axios 傳送給你的後端
  // axios.post('https://projectname.example.come.tw/api/auth/google', { code: response.code })
}

const handleLoginError = () => {
  console.error("Google 登入失敗")
}
</script>

<template>
  <div class="login-container">
    <h2>入口網登入</h2>
    <GoogleLogin :callback="handleLoginSuccess" :popup-type="'CODE'" @error="handleLoginError" />
  </div>
</template>

情境二：純前端（SPA 單頁應用，無後端）

如果你的 Vue 3 是一個完全靜態的網站，沒有任何自己的後端資料庫，單純只想確認「他是誰」或者想在前端呼叫 Google API（例如讀取他的 Google Calendar）。

在這種模式下，你的 OAuth 2.0 用戶端 ID 類型一樣選擇：「網頁應用程式」。但流程會走「隱含授權 (Implicit Flow)」，直接在前端取得 access_token。

安全警告： 因為純前端沒有秘密可言，你的 Client Secret 絕對不能寫在 Vue 3 的原始碼或 .env 裡（因為打包後任何人都能看光）。在 Google Console 建立憑證時，這種模式通常不需要用到 Client Secret。

前端設定差異：

如果你是用上面提到的 vue3-google-signin，在按鈕上就不要加 :popup-type="'CODE'"，它預設會直接在前端回傳一串 JWT（身分憑證），你可以直接解開它來取得使用者的 Email 和姓名：

JavaScript

import { decodeCredential } from 'vue3-google-signin'

const handleLoginSuccess = (response) => {
  // 直接在前端解密 Google 回傳的使用者資訊
  const userData = decodeCredential(response.credential)
  console.log("使用者資料:", userData) // 包含 email, name, picture
}

搭配你上一題的測試/正式環境，Vite 該如何設定？

因為你有兩個環境，請在 Vue 3 專案根目錄建立兩個環境變數檔案：

1. .env.development (測試環境用)程式碼片段VITE_GOOGLE_CLIENT_ID=你的測試環境_CLIENT_ID.apps.googleusercontent.com
2. .env.production (正式環境用)程式碼片段VITE_GOOGLE_CLIENT_ID=你的正式環境_CLIENT_ID.apps.googleusercontent.com

當你執行 vite preview 或 vite build 時，Vite 就會自動根據環境抓取正確的 Client ID，完美對應到正式環境與測試環境了！

這裡幫大家整理了 4 個超實用的方法，不管是想要神級的操作體驗，還是懶得安裝任何軟體的速成法，這篇通通有。

方法 1 ： VS Code 神級流暢體驗（強烈推薦）

如果你平常就在用 Visual Studio Code 寫程式，這絕對是最頂的選擇，可以享受一邊打字、旁邊畫面一邊即時更新的快感。

1. 打開 VS Code ，到擴充功能市場搜尋並安裝 PlantUML 這個套件。
2. 注意，這裡有一個重要的小跟班需要安裝。因為 PlantUML 畫圖需要 Graphviz 的協助，請打開命令提示字元輸入 winget install Graphviz 來快速搞定它。
3. 如果真的懶得在電腦安裝 Graphviz 怎麼辦？也可以直接到 VS Code 的設定裡搜尋 plantuml.server ，把它改成連到官方的線上伺服器來幫你畫圖。
4. 萬事俱備後，打開 .puml 檔案，按下 Alt + D ，右邊就會跳出即時預覽畫面。

方法 2 ： JetBrains 宇宙（ IntelliJ 、 PyCharm 專屬）

如果你是 JetBrains 系列 IDE 的忠實粉絲，根本不用離開視窗，裡面就自帶強大功能。

1. 點選 File 進入 Settings ，接著找到 Plugins 區塊。
2. 搜尋 PlantUML Integration 並點擊安裝。
3. 把 IDE 重新啟動。
4. 接下來只要打開任何 .puml 檔案，右邊就會自動長出專屬的預覽視窗，完全不用操心。

方法 3 ： 獨立 Java 檔案（免安裝開發工具）

如果不想為了看張圖就開啟笨重的開發工具，也可以用官方提供的輕量級 Java 小工具。

1. 請先確保電腦裡有安裝 Java 執行環境。
2. 到 PlantUML 官方網站 下載 plantuml.jar 檔案。
3. 打開命令提示字元，切換到下載的資料夾，輸入 java -jar plantuml.jar -gui 這一行指令。
4. 畫面上就會跳出一個小巧的視窗，只要選好放 .puml 檔案的資料夾，每次只要存檔，它就會自動幫你刷新圖片。

方法 4 ： 線上免安裝（終極懶人法）

如果只是臨時要看一下檔案，連一秒鐘都不想浪費在安裝上，那就直接交給瀏覽器吧。

• 官方線上伺服器：直接把程式碼複製貼上到 PlantUML Web Server 就能立刻看到結果。
• 網頁編輯器： PlantText 是一個非常受歡迎的線上即時編輯器，畫面好看而且專為 PlantUML 設計，非常適合臨時救急。

在 Windows 執行 ssh 顯示錯誤訊息

C:\Users\max>ssh 4.216.213.123
Bad permissions. Try removing permissions for user: BUILTIN\\Users (S-1-5-32-545) on file C:/Users/max/.ssh/vm-max-pc-key.pem.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'C:\\Users\\max/.ssh/vm-max-pc-key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "C:\\Users\\max/.ssh/vm-max-pc-key.pem": bad permissions
azureuser@4.216.213.123: Permission denied (publickey).

在使用 Windows 系統連線到遠端伺服器的時候，是不是常常遇到 SSH 跟你鬧脾氣？

畫面跳出一大串警告，寫著 WARNING UNPROTECTED PRIVATE KEY FILE ，然後無情地拒絕連線。這其實不是你的伺服器壞掉，而是 SSH 的安全機制太過傲嬌。它覺得你的金鑰檔案太過公開，像是把家裡鑰匙直接貼在大門口一樣危險，所以故意裝作不認識你。

這個問題通常是因為金鑰檔案的權限開太大，導致系統內的其他使用者也能讀取。要解決這個尷尬的狀況，有兩種快速的方法可以馴服它。

第一種方法是使用命令提示字元。

請開啟命令提示字元，並依序輸入以下指令。記得將路徑換成自己的金鑰檔案路徑。

第一步是取消繼承權限，指令為

icacls C:\Users\your_username\.ssh\my_key.pem /inheritance:r

第二步是重新給予自己完整的控制權限，指令為

icacls C:\Users\your_username\.ssh\my_key.pem /grant:r your_username:F 

第二種方法是使用圖形介面，適合喜歡用滑鼠點擊的人。

請打開檔案總管，找到金鑰檔案。在檔案上按右鍵選擇內容，切換到安全性標籤，接著點擊進階。

在進階安全性設定視窗中，點擊停用繼承，並選擇將繼承的權限轉換為此物件的明確權限。

最後在權限項目清單中，找到 Users 這個群組並將它移除，只留下自己的使用者帳號擁有存取權限。點擊套用並確定就完成了。

設定完成之後，再次嘗試原本的連線指令，應該就能順利連上伺服器。如果還是失敗，可以嘗試在指令中明確加上減 i 參數，例如

ssh -i C:\Users\your_username.ssh\my_key.pem user@1.2.3.4 

這樣就能成功登入了。

如果你現在用的是 Vue 3 搭配 Element Plus，而你在拿掉的瞬間，你的網頁基本上就半身不遂了。

• 短期（建議）： 維持 Element Plus，接受 unsafe-inline Medium 風險，專注業務功能。
• 中期： 若資安掃描壓力大，評估 Naive UI 替換（相同 Vue 生態、學習成本低）。
• 長期： 新專案直接選 React + shadcn/ui 或 React + Mantine，避免此問題。

兩大資安大哉問： 到底能不能直接拔掉？

我們先把問題拆成兩個層面來看。

1. 在 FastAPI 設定 CSP 跟在 Nginx 設定，有差嗎？

答案是： 完全沒有差別。

瀏覽器是很單純的，它只看最後收到的 HTTP response header。 不管這個資安政策是後端框架 FastAPI 吐出來的，還是前端大門 Nginx 塞給它的，對瀏覽器來說都長得一樣。

目前專案只有在 FastAPI 設定，那就繼續留在那邊就好，不需要特地搬家。

2. 移除 unsafe-inline 之後，Element Plus 還能動嗎？

答案是： 絕對會壞掉，而且壞得很難看。

如果你的 CSP 政策直接移除了 unsafe-inline，下面這些畫面上最亮眼的主角會集體罷工：

• el-select / el-dropdown： 下拉選單直接迷路，位置飛到九霄雲外或是乾脆隱形。
• el-tooltip / el-popover： 滑鼠移過去原本該跳出的提示，現在比你的前任還要冷淡，完全沒反應。
• el-dialog： 彈出視窗直接彈歪，跟你的預期完全對不上。
• el-table 固定列： 說好要固定的欄位，現在放飛自我跟著一起滾動。

為什麼會這樣？ 因為這些元件在運作時，JavaScript 會在幕後瘋狂計算畫面的座標，然後直接把 style="top: 200px; left: 150px;" 這種類型的行內樣式塞進 HTML 標籤裡。

當你把 unsafe-inline 拿掉，瀏覽器就會化身鐵面判官，只要看到這種行內樣式，一律當成非法入侵直接封鎖。 結果就是你的 CSP 報告看起來滿分，但使用者的畫面看起來像一場災難。

那難道無解了嗎？ 現代資安的標準解法

好消息是，我們不需要為了資安把整個 Element Plus 換掉（ 畢竟換框架是會出人命的 ）。 在 CSP Level 3 的現代標準中，資安政策已經被細分得更聰明了。

以前的 style-src 是一刀切，但現在我們可以把「 標籤 」和「 屬性 」分開管理。

你可以試試看這套完美的資安配置：

HTTP

Content-Security-Policy: style-src-elem 'self' https://cdnjs.cloudflare.com; style-src-attr 'unsafe-inline';

這段設定的意思其實就是跟瀏覽器講悄悄話：

• style-src-elem ‘self’： 只要有人想用 <style> 標籤或外掛惡意 CSS 檔案來劫持網頁，一律給我擋掉！ 這招直接封鎖了最危險的 CSS 注入攻擊。
• style-src-attr ‘unsafe-inline’： 至於 HTML 標籤裡面的 style="..." 屬性，我們就開個特權給它過吧。

改前 vs 改後 戰力分析

這樣改到底差在哪裡？ 我們直接看對比：

• <style> 注入攻擊： 改前是允許的（ 超危險 ），改後直接封鎖（ 安全 ）。
• 外掛惡意 CSS 檔案： 改前是允許的（ 超危險 ），改後直接封鎖（ 安全 ）。
• Element Plus 動態定位： 改前正常，改後依然正常運作。
• 資安掃描器的警告： 改前會跳出黃牌警告，改後警告直接消失。

結論

想兼顧資安跟漂亮的 UI，不需要直接把 unsafe-inline 趕盡殺絕。

透過 style-src-elem 和 style-src-attr 的分工合作，你既能把大門關緊防範黑客，又能留個小窗讓 Element Plus 的元件繼續正常跳舞。 這才是現代工程師優雅的解決之道。

結論上來說，改用

簡單來說，如果你的 CSP （ 網頁安全政策 ）開了 unsafe-inline ，就等於是在大門裝了密碼鎖，卻把密碼用便利貼貼在門口一樣。駭客只要找到機會塞一段惡意腳本（ XSS 攻擊 ），你的網站就直接變成他的遊樂場。

但是偏偏像是 Google Tag Manager （ GTM ）這種必裝的分析工具，官方給的程式碼裡面就是有一大段 Inline Script ：

HTML

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

既想要防禦 XSS 攻擊，又不能把 GTM 拔掉，這時候你有兩條路可以走，讓我們來看看這兩個相愛相殺的解決方案。

方案一：使用 Nonce （ 一次性密碼鎖 ）

這個方法就像是去看演唱會，每次進場工作人員都會在你的手上蓋一個當天限定、過期失效的印章。

在 CSP 標頭（ Header ）裡，你可以這樣設定：

HTTP

Content-Security-Policy: script-src 'nonce-每天換的神秘亂數密碼'; img-src www.googletagmanager.com

然後在你的網頁程式碼中，那段 GTM 的標籤也必須帶上相同的密碼：

HTML

<script nonce='每天換的神秘亂數密碼'>
  // GTM 的扣（Code）放這裡
</script>

工程師真心話

• 優點：超級安全。因為駭客根本猜不到你下一個 Request 的亂數密碼是什麼，就算他成功塞了惡意指令，也會因為沒有通關密碼而被瀏覽器直接擋在門外。
• 缺點（ 也就是坑 ）：這非常考驗後端的大腦。你的伺服器必須在「 每次 」收到請求時，都用高強度的加密演算法生出一組全新的隨機字串。最慘的是，你的網頁從此跟「 回應快取 」（ Response Cache ）說再見，因為一旦網頁被快取，密碼就不會變了，那這個鎖就形同虛設。

方案二：使用 Hash （ 驗收指紋認證 ）

如果你的網站是 SPA （ 單頁應用程式 ），或是部署在 GitHub Pages 這種根本沒有後端可以幫忙生密碼的靜態伺服器，那 Hash 就是你的救星。

這個概念是，瀏覽器會直接去核對這段程式碼的「 指紋 」。

步驟非常簡單，把 <script> 到 </script> 之間的程式碼內容，丟到 SHA256 線上計算工具 裡面去跑一下，會得到一串像是 0bbd063b7... 的雜湊值（ Hash ）。

接著把這串指紋放進你的 CSP 設定裡：

HTTP

Content-Security-Policy: script-src 'sha256-計算出來的那串指紋'; img-src www.googletagmanager.com

工程師真心話

• 優點：前端自己就能搞定，不需要後端伺服器配合，而且網頁依然可以開開心心地做快取，提升載入速度。
• 缺點（ 最雷的地方 ）：
  1. 字元敏感度破表：SHA256 是一個極度龜毛的演算法。只要你的程式碼裡面多了一個空格、少了一個換行，甚至不同工程師的電腦存檔時，斷行符號一個是 LF （ \n ）一個是 CRLF （ \r\n ），算出來的指紋就完全不一樣。指紋一對不上，你的 GTM 就會直接被 CSP 射下來。
  2. 維護地獄：哪天行銷團隊突然要求修改 GTM 裡面的參數，只要動到一個字，你就必須重新計算一次 Hash 值、重新更新 CSP 標頭。如果交接沒做好，後續接手的工程師改了程式碼發現網站功能壞掉，可能要在電腦前哭著找兇手找很久。

總結防禦指南

想要高枕無憂、後端架構也撐得住，請選 Nonce 。

如果是靜態網站、追求速度與快取，請選 Hash ，但每次改動程式碼時，請記得去燒香拜拜順便更新指紋。

總之，快把 unsafe-inline 從你的 CSP 裡面拿掉，別再讓你的網站裸奔了。