這是一張有關標題為 從 Wi-Fi 密碼到網站漏洞：常見資安風險與防範措施 的圖片

從 Wi-Fi 密碼到網站漏洞：常見資安風險與防範措施

從 Wi-Fi 弱密碼、網域控管腳本到未加密 Cookie 與 API 驗證缺陷，完整揭示常見駭客入侵手段與對應防護措施，結合篡改漏洞、未授權存取與提升權限案例，警惕資安意識與長期風險管理，以確保系統與使用者資訊免遭攻擊並維護整體安全，強調 BitLocker 加密與嚴謹 API 審核等關鍵要點，推行多層防護。

前言

在數位化時代，網路安全（Cybersecurity）已成為企業與個人不可忽視的議題。然而，在臺灣，許多公司、機構甚至個人使用者，仍然忽略了基本的資安防護，使得駭客能夠輕鬆入侵系統，竊取機密資訊，甚至造成業務癱瘓。

常見的資安漏洞並不需要高深的駭客技術，反而是因為基本的防護意識不足，讓攻擊者得以輕易突破。本文章會探討臺灣最常見的駭客攻擊手法，包括弱密碼攻擊、Cookie 權限提升、網站 API 漏洞等進行探討。

這些攻擊手法看似簡單，但往往是因為資安意識不足或防護措施不完善，才導致嚴重的漏洞。本文分享的內容，皆來自實際案例與觀察，旨在提高對常見資安風險的警覺性。

Wi-Fi 密碼安全風險

臺灣許多企業與公共場所的 Wi-Fi 密碼設定過於簡單且可預測，使駭客無需使用暴力攻擊（brute-force attack）或進階攻擊技術，即可輕易入侵內部網路。

主要風險點：

  1. 可預測密碼（如 12345678、88888888）。
  2. 公司/市內電話。
  3. 統一編號（unified business number，UBN）。
  4. 個人手機號碼。

使用弱密碼，極易被字典攻擊，或是公司等公開資訊、個人手機號碼，能夠透過公開資料查詢或是社交工程攻擊。因此建議使用特殊符號，或是更長的可讀式密碼進行設定。

例如某 A 公司的密碼可以設為：

1

Thisispasswordforacompany2025$

或是家裡的密碼，可以設定為手機+特殊符號+單詞：

1

0910000123@home

使用長度較長且具可讀性的密碼能有效降低被破解的風險，並遠比純數字密碼來得安全。

雖然使用完全隨機的密碼（如 ^Wa091UW!N@U123QQ-USA）能有最高的安全性，但對一般使用者而言，輸入與記憶困難，反而降低了實際應用的可行性。

網域控管自動化腳本漏洞

公司 MIS 工程師在管理使用者電腦時，通常會透過 網域控管（domain management） 來統一管理與設定權限，並即時監控使用者的行為，例如 登入 IP、連線狀態、存取紀錄 等。

這些自動化腳本通常存在於特定的網域網址，可透過 Autoruns 檢查電腦開機時執行的腳本，以識別並獲取伺服器路徑。

部分漏洞來自於系統將 Administrator 帳號的密碼明文儲存於伺服器，且未採取適當的加密與存取控制。

1
2

net user Administrator /active:yes
net user Administrator XXXXXXXXX

只要獲取此檔案，即可解析出本機最高權限使用者的密碼，進而提升自身在該電腦上的存取權限。

此外，部分 MIS 為了簡化管理，會將需具備管理權限的安裝檔案獨立打包，以便基本使用者自行安裝。

該打包的執行檔可透過 Win32 API 提升自身權限，或將修改密碼的腳本封裝為可執行檔案，並在執行時於系統特定位置解包腳本，執行後再自動刪除。然而，若未妥善控管，此類機制可能帶來潛在的安全風險。

我們可以透過解包該執行檔中的密碼，從中提取修改密碼的腳本。該密碼通常以 ASCII 格式 記錄，解碼後即可取得明文密碼。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@shift /0
@echo off
setlocal enableDelayedExpansion
set "str="
for %%H in (0x71 0x71 0x57 0x33 0x6C 0x6C 0x35 0x24) do (
	for /l %%N in (%%H 1 %%H) do cmd /c exit %%N
	set "str=!str!!=ExitCodeASCII!"
)
net user admin_account /add
net user admin_account /active:yes
net user admin_account /expires:never
net user admin_account !str!
net user administrator !str!
net user administrator /active:no
net localgroup Administrators admin_account /add
wmic UserAccount where Name="admin_account" set PasswordExpires=False

得到密碼後，相當於取得每一台電腦的大門，是一個蠻嚴重的漏洞。

使用 WinPE 繞過登入限制並獲取最高權限

如果希望獲取電腦的最高權限或存取硬碟檔案，在 Windows 未啟用 BitLocker 的情況下，可透過 WinPE（如 USBOX 7.0）等工具進入系統，直接修改或提取相關檔案。

使用 WinPE 進入系統後，開啟命令提示字元，先對放大鏡（Magnify.exe）進行備份，然後將該檔案替換為命令提示字元（cmd.exe）。

1
2
3

cd C:\windows\system32
ren Magnify.exe Magnify.back
copy cmd.exe Magnify.exe

重新啟動電腦並進入Windows 登入畫面，點擊右下角的輕鬆存取，選擇並啟動放大鏡，此時系統將開啟cmd.exe，並以SYSTEM 權限執行。

接著，執行以下指令來啟用本機 Administrator 帳號，並將密碼設定為 MY_NEW_PASSWORD：

1
2

net user administrator /active:yes
net user administrator MY_NEW_PASSWORD

成功後，復原系統檔案：

1
2
3

cd C:\windows\system32
del Magnify.exe
ren Magnify.back Magnify.exe

重新啟動並以 administrator 登入，就可以進行你想做的事情了。

記得重開機要確定系統是否有寫入相關的腳本，有些腳本會在登入時將 Administrator 底下的所有使用者清除。因此建議斷網操作。

要防止這種 WinPE 讀取系統檔案的方式，可以藉由啟用 BitLocker 加密，以防止透過 WinPE 讀取磁碟內容。

部分網頁使用 Cookie 驗證使用者的登入狀態，為資安漏洞的一環。

在先前《CVE-2024-9970: NewType FlowMaster BPM Plus 系統的特權升級漏洞分析》中，曾提及某系統透過 Cookie 來驗證身份，其中使用者 ID 以 Base64 編碼儲存在 Cookie 中。由於缺乏適當的驗證與防範措施，攻擊者僅需修改 Cookie 中的 ID，即可冒充其他使用者。

大多數的實作會依照以下流程進行：

  1. 使用者登入驗證：使用者提交憑證（如帳號密碼），伺服器驗證後產生唯一的 session token 或 JWT，該 token 內部可能包含使用者 ID 及其他身份資訊。
  2. 憑證處理與傳送：伺服器將 token 透過 Cookie 傳遞給使用者端。現代安全實作會對 Cookie 內容進行加密或數位簽章，以防篡改。
  3. 後續請求驗證：使用者瀏覽器在後續請求中自動攜帶 Cookie，伺服器則根據 token 的合法性、完整性與有效性來確認使用者身份與權限。
  4. 安全屬性設定：為防止跨站腳本攻擊（cross-site scripting，XSS）等風險，通常會在 Cookie 中設定 HttpOnly 與 Secure 屬性，確保只有伺服器能讀取，且僅在加密通訊下傳輸。

該網站有寫入 ASP.NET_SessionId 的 Cookie，這是 ASP.NET 內建的 Session 管理機制自動生成與管理的。然而，最終的實作方式卻引入自行實作的安全性漏洞。

當使用者於網頁完成登入程序後，伺服器與用戶端透過 Cookie 進行身份驗證，該 Cookie 實質上充當數位身分證。若攻擊者能夠竊取此 Cookie，便可偽造身份繞過密碼驗證機制，進而存取受保護的系統資源。

取得使用者的 Cookie 有很多辦法，例如：

  1. 透過瀏覽器的擴充功能進行匯出與匯入
  2. 中間人攻擊（man-in-the-middle, MiTM）
  3. 跨站腳本（XSS）攻擊
  4. 本機存取或相關工具
  5. 其他….

由於大多數網站不會主動驗證使用者的裝置與環境變化，因此當 Cookie 被竊取時，往往難以察覺。為降低 Cookie 外洩風險，必須確保裝置僅由本人使用，以防未授權存取。進階的防護措施包括安裝防毒軟體，以防止惡意軟體竄改系統根憑證，進而攔截或竊取敏感資料。

不安全的 API 驗證機制導致未授權存取與資料篡改

在 API 設計上，部分網站過度信任用戶端提供的憑據，未透過後端進行嚴格驗證，導致攻擊者得以繞過身份驗證機制，進行未授權存取或資料篡改，嚴重影響系統安全性。

此類 API 請求內容可透過 Fiddler AutoResponder 或瀏覽器內建的 開發人員工具 進行攔截與修改，透過本機覆寫請求或回應來影響伺服器端的處理結果，進而產生安全風險。

為確保 API 的安全性，應採取以下措施：

  • 後端驗證：所有請求應由伺服器進行完整驗證，而非僅依賴用戶端提供的憑據。
  • 請求簽章：使用 HMAC、JWT 或其他加密機制，確保 API 請求的完整性與合法性，防範請求遭篡改。
  • 回應完整性驗證：對回應資料進行完整性檢查，避免攻擊者攔截並修改回應內容來欺騙系統。

API 設計應優先考量安全性，以降低未授權存取與資料篡改的風險，確保系統與使用者的資料安全。

以下為三個可能的 API 安全缺陷案例，供參考：

API 驗證機制漏洞導致未授權權限提升

某網站的登入機制依賴後端 API 進行身份驗證，並根據驗證回傳結果開啟特定功能。然而，由於系統完全依賴 API 回應內容來決定頁面顯示狀態，攻擊者可攔截並修改 API 回應，使其獲取未授權的管理員權限，進一步造成 權限提升 或 資料洩露。

API 參數驗證缺失導致價格篡改漏洞

在某訂餐平台中，當使用者將商品加入購物車時，前端會向 API 發送請求，包含 金額、商品 ID 等資訊。然而，由於該 API 未對金額參數進行伺服器端驗證，也未對請求內容進行加密，攻擊者可透過攔截 API 請求，手動修改商品價格，導致以低於實際售價的金額完成交易，進而造成營收損失。

郵件 API 欄位驗證不足導致寄件人偽造漏洞

某網站的「匯出報表」功能允許使用者透過 API 發送報表至指定信箱。原始設計中，API 預設的寄件者為 admin@google.com，收件者則由使用者指定。然而，由於 API 允許用戶端直接提交寄件者與收件者的電子郵件，且後端未限制寄件者欄位變更，攻擊者可偽造寄件人身份，冒充任意郵件地址發送惡意郵件。

上述案例顯示了 API 驗證機制薄弱所帶來的嚴重風險，因此企業在設計 API 時，應確保：

  • 驗證機制嚴謹，避免憑據篡改與身份偽造。
  • 請求與回應的完整性受保護，防範惡意資料篡改。
  • 關鍵參數不可由用戶端直接控制，降低業務風險與攻擊面。

透過完善的安全機制，企業可大幅減少 API 漏洞帶來的資安風險，確保系統與使用者資料的安全性。

結論

隨著數位化發展，駭客攻擊手法日益精進，但許多企業與個人仍忽視基本資安防護，使系統容易遭受入侵。弱密碼、網域控管漏洞、Cookie 權限提升、API 驗證缺陷等問題，皆源於資安意識不足與防護機制不完善。

為降低風險，應採取以下措施：

  1. 強化身份驗證：使用強密碼，啟用 雙因素驗證（2FA），防止帳戶被盜用。
  2. 確保網域與權限安全：加密管理腳本，限制高權限帳戶存取，防範未授權操作。
  3. 提升 Cookie 與會話管理：設定 HttpOnly、Secure，實施 Session Timeout，降低憑證被竊取的風險。
  4. 永遠不要信任用戶端傳來的資料：所有來自用戶端的輸入（API 請求、Cookie、URL 參數、表單資料等）皆應在伺服器端驗證與過濾，防範 SQL 注入、XSS、權限提升等攻擊。
  5. 選擇安全的系統方案：避免使用 低成本、無技術支援 的系統，並定期進行安全測試，以確保符合資安標準。
  6. 啟用 BitLocker 加密：防止透過 WinPE 或實體存取 竊取磁碟資料。

資安是持續演進的風險管理，企業與個人應建立長期防護策略，定期檢測漏洞、監控異常行為，並強化資安意識，以確保資料與系統的安全。

版權所有 © 2023 - 2025 WellWells
主題 Stack 由 Jimmy 設計