# 安全思維與攻防基礎

::: tip 前言
**你的網站安全嗎？** 很多開發者覺得「安全是安全團隊的事」，直到自己的專案被攻擊、使用者資料外洩。安全不是可選項，而是每個開發者的基本功。

本章帶你建立安全思維，理解最常見的 Web 安全威脅和防禦方法。
:::

**這篇文章會帶你學什麼？**

| 章節 | 內容 | 核心概念 |
|-----|------|---------|
| **第 1 章** | 安全思維模型 | 像攻擊者一樣思考 |
| **第 2 章** | 常見 Web 攻擊 | XSS、SQL 注入、CSRF |
| **第 3 章** | 防禦策略 | 輸入驗證、輸出編碼、權限控制 |
| **第 4 章** | 安全檢查清單 | 專案上線前的安全自查 |

學完本章，你將具備基本的安全意識，能識別和防禦最常見的 Web 安全威脅。

---

## 0. 全景圖：開發者需要懂安全的動機

想像你建了一棟房子，功能齊全、裝修漂亮，但忘了裝鎖。安全漏洞就是程式碼世界裡「忘了裝的鎖」。

::: tip 安全的核心原則
- **最小權限**：只給必要的權限，不多給一分
- **縱深防禦**：不依賴單一防線，層層設防
- **永不信任輸入**：所有來自外部的資料都可能是惡意的
- **安全預設**：預設設定應該是安全的，而不是方便的
:::

---

## 1. 常見 Web 攻擊

透過下面的互動元件，了解三種最常見的 Web 攻擊原理（僅用於教育目的）：

<WebSecurityDemo />

### 1.1 XSS（跨站腳本攻擊）

攻擊者將惡意腳本注入到網頁中，當其他使用者造訪時，腳本在他們的瀏覽器中執行。

```javascript
// 危險：直接將使用者輸入插入 HTML
element.innerHTML = userInput
// 如果 userInput 是 <script>惡意程式碼</script>，就會執行

// 安全：使用 textContent 或轉義
element.textContent = userInput
// 或使用框架的自動轉義（Vue 的 {{ }}、React 的 JSX）
```

**防禦要點**：
- 輸出時轉義 HTML 特殊字元（`<`, `>`, `&`, `"`, `'`）
- 使用現代框架的自動轉義機制
- 設定 `Content-Security-Policy` HTTP 標頭

### 1.2 SQL 注入

攻擊者透過構造特殊輸入，篡改 SQL 查詢的邏輯。

```javascript
// 危險：字串拼接 SQL
const query = `SELECT * FROM users WHERE name = '${userInput}'`
// 如果 userInput 是 ' OR '1'='1，就會回傳所有使用者

// 安全：使用參數化查詢
const query = 'SELECT * FROM users WHERE name = ?'
db.execute(query, [userInput])
```

**防禦要點**：
- 永遠使用參數化查詢 / 預編譯語句
- 使用 ORM 框架（如 Prisma、Sequelize）
- 限制資料庫帳號權限

### 1.3 CSRF（跨站請求偽造）

攻擊者誘導已登入的使用者造訪惡意頁面，利用使用者的登入狀態發起請求。

**防禦要點**：
- 使用 CSRF Token
- 檢查 `Referer` / `Origin` 標頭
- 關鍵操作使用 POST 而非 GET
- Cookie 設定 `SameSite` 屬性

---

## 2. 防禦策略

### 2.1 輸入驗證

```javascript
// 白名單驗證：只允許預期的格式
function isValidEmail(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)
}

// 長度限制
function isValidUsername(name) {
  return name.length >= 2 && name.length <= 50
}
```

### 2.2 敏感資料保護

| 資料類型 | 保護措施 |
|---------|---------|
| 密碼 | bcrypt/argon2 雜湊，永不明文儲存 |
| API 金鑰 | 環境變數，不提交到程式碼儲存庫 |
| 使用者資料 | HTTPS 傳輸，加密儲存 |
| 工作階段令牌 | HttpOnly + Secure + SameSite Cookie |

### 2.3 HTTP 安全標頭

```
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000
```

---

## 3. 安全檢查清單

上線前，用下面的互動元件檢查你的專案安全狀況：

<SecurityChecklistDemo />

### 3.1 開發階段

- [ ] 所有使用者輸入都經過驗證和轉義
- [ ] 使用參數化查詢，無 SQL 拼接
- [ ] 密碼使用 bcrypt 等演算法雜湊儲存
- [ ] 敏感設定透過環境變數管理
- [ ] `.env` 檔案已加入 `.gitignore`

### 3.2 部署階段

- [ ] 啟用 HTTPS
- [ ] 設定安全 HTTP 標頭
- [ ] 關閉除錯模式和詳細錯誤訊息
- [ ] 資料庫使用最小權限帳號
- [ ] 定期更新依賴（`npm audit`）

---

## 4. AI 助力：用大模型提升安全防護

大模型可以充當你的「安全顧問」，幫你審計程式碼漏洞、產生安全方案。

### 4.1 程式碼安全審計

> **提示詞**：
> ```
> 請對以下程式碼進行安全審計，檢查是否存在：
> - XSS 漏洞（未轉義的使用者輸入）
> - SQL 注入（字串拼接查詢）
> - CSRF 風險（缺少 Token 驗證）
> - 敏感資料外洩（硬編碼金鑰、明文密碼）
> 對每個問題給出風險等級、具體位置和修復方案。
>
> [貼上你的程式碼]
> ```

### 4.2 產生安全設定

> **提示詞**：
> ```
> 我的專案使用 Express.js + PostgreSQL，即將部署上線。
> 請產生一份完整的安全設定清單，包括：
> - HTTP 安全標頭設定程式碼
> - CORS 設定
> - 資料庫連線的安全設定
> - 環境變數管理方案
> 給出可直接使用的程式碼片段。
> ```

### 4.3 解釋漏洞原理

> **提示詞**：
> ```
> 用一個具體的例子，解釋 CSRF 攻擊的完整流程：
> 1. 攻擊者如何構造惡意頁面
> 2. 為什麼瀏覽器會自動攜帶 Cookie
> 3. 伺服器端如何用 CSRF Token 防禦
> 用程式碼演示攻擊和防禦的完整過程。
> ```

::: tip AI 使用建議
AI 的安全審計不能替代專業的安全測試。把它當作第一道篩查，關鍵系統仍需專業安全團隊審計。
:::

---

## 5. 總結

1. **安全思維**：永不信任外部輸入，最小權限，縱深防禦
2. **常見攻擊**：XSS、SQL 注入、CSRF 是最高頻的 Web 安全威脅
3. **防禦策略**：輸入驗證、輸出編碼、參數化查詢、安全 HTTP 標頭
4. **安全習慣**：上線前過安全檢查清單，定期審計依賴

::: tip 終極思考
安全不是一次性的工作，而是貫穿開發全過程的習慣。就像開車繫安全帶——不是因為你預期會出事故，而是因為這是基本的安全意識。**寫每一行程式碼時都問自己：如果這個輸入是惡意的，會發生什麼？**
:::

---

## 延伸閱讀

- **OWASP Top 10**：Web 應用安全十大風險清單，每個開發者都應該了解。
- **實用工具**：使用 `npm audit` 檢查依賴漏洞，使用 ESLint 安全外掛檢查程式碼。
- **深入學習**：了解 HTTPS 原理、JWT 安全實踐、OAuth 2.0 安全考量。
- **安全社群**：關注安全公告，及時修補已知漏洞。