## HTTP協定
### 1. 運作方式

* 客戶端發出請求(Request) -> 伺服器給出回應(Response)
* 流程:
* 使用者在瀏覽器中輸入網址
-> 瀏覽器送出一個Request給網站伺服器
-> 伺服器收到後處理，送回一個response
-> 瀏覽器根據回應內容顯示網頁

如果是要打開一個網頁:

| 欄位 | 說明 |
| ------------------- | ---------------------------------------------------- |
| **Request URL** | 請求的網址：`http://127.0.0.1:5000/home`（本機伺服器 `/home` 頁面） |
| **Request Method** | HTTP 方法為 `GET`，表示取得頁面 |
| **Status Code** | `200 OK`：伺服器成功處理請求 |
| **Remote Address** | 伺服器地址：127.0.0.1:5000（本機） |
| **Referrer Policy** | `strict-origin-when-cross-origin`：跨來源時只送出 origin 資訊 |

- Response

| 欄位 | 說明 |
| ------------------- | ---------------------------------------------------- |
| **Connection** | `close`：伺服器請求完後關閉連線 |
| **Content-Length** | `510`：回應的內容長度（byte 數） |
| **Content-Type** | `text/html; charset=utf-8`：網頁內容，UTF-8 編碼 |
| **Date** | 回應的時間：2025/07/26 14:16:48 GMT |
| **Server** | Werkzeug/3.1.3 Python/3.10.11（Flask 預設的開發用伺服器） |
| **Vary** | `Cookie`：根據不同 cookie 值可能回傳不同內容（通常用於快取控制） |

- Request

| 欄位 | 說明 |
| ----------------------------- | ----------------------------------------------------- |
| **Accept** | 告訴伺服器可接受哪些格式，像 HTML、圖片等 |
| **Accept-Encoding** | 指定壓縮方式（gzip、br 等）以節省流量 |
| **Accept-Language** | 優先語言：中文（台灣） > 中文 > 英文（美國） |
| **Cache-Control** | `max-age=0`：告訴伺服器不要使用快取 |
| **Connection** | `keep-alive`：希望保持連線不關閉（節省建立新連線的成本） |
| **Cookie** | 包含 session ID：`session=eyJ1c2VyIjoi...`，用於識別登入狀態 |
| **Host** | 主機資訊：127.0.0.1:5000 |
| **Referer** | 前一頁是：[http://127.0.0.1:5000/](http://127.0.0.1:5000/) |
| **Sec-CH-UA / Sec-Fetch-XXX** | 安全性相關的 HTTP Client hints，用來識別瀏覽器、平台等 |
| **User-Agent** | 瀏覽器資訊：Chrome 138 on Windows 10 |

@app.route('/home')
def home():
    if 'user' in session:                          # ← session 仍存在，允許顯示頁面
        return render_template('home_page.html', user=session['user'])
    else:
        return redirect(url_for('index'))          # 若無 session 則跳轉回登入

登入指令:
| 欄位 | 說明 |
| ------------------- | ---------------------------------------------------------------------------------- |
| **Request URL** | 請求登入的 URL：`http://127.0.0.1:5000/login` |
| **Request Method** | POST：提交登入表單 |
| **Status Code** | `302 FOUND`：伺服器重新導向至 `/home`（登入成功的典型行為） |
| **Remote Address** | 127.0.0.1:5000 |
| **Referrer Policy** | `strict-origin-when-cross-origin` |
| **Connection** | close |
| **Content-Length** | 197 |
| **Content-Type** | `text/html; charset=utf-8` |
| **Date** | 回應時間 |
| **Location** | `/home`：告訴瀏覽器重導向至此頁 |
| **Set-Cookie** | 設定 session cookie：`session=eyJ1c2VyIjoi...; HttpOnly; Path=/`，表示登入成功並儲存使用者 session |
| **Vary** | Cookie：同上，用來控制快取行為 |

| 欄位 | 說明 |
| ---------------------------------------------- | ------------------------------------------ |
| **Accept / Accept-Encoding / Accept-Language** | 同上 |
| **Connection** | `keep-alive` |
| **Content-Length** | 28：提交的表單資料長度 |
| **Content-Type** | `application/x-www-form-urlencoded`：常見表單格式 |
| **Origin** | `http://127.0.0.1:5000`：來源頁面與目標相同（同源請求） |
| **Referer** | `http://127.0.0.1:5000/`：前一頁為登入頁 |
| **Host / Sec-CH-UA / User-Agent** | 同上 |

@app.route('/login', methods=['POST'])
def login():
    account = request.form.get('account')          # ← 對應 request body 的帳號欄位
    password = request.form.get('password')        # ← 對應 request body 的密碼欄位

    if account in users and users[account] == password:
        session['user'] = account                  # ← 對應伺服器回應中的 Set-Cookie（session）
        return redirect(url_for('home'))           # ← 對應 status code: 302 和 Location: /home
    else:
        error = '帳號或密碼錯誤'
        return render_template('login_page.html', error=error)

### 2. 常見的HTTP method

|名稱|主要意義|例子|
|----|----|----|
|GET|取得後端資源(請求獲取資料)|打開網頁|
|POST|提交資料，通常用於新增資料|送出表單、登入帳號|
|PUT|送出檔案至伺服器上(更新指定資料)|修改個人資料|
|DELETE|刪除資料|刪除文章|

### 3. HTTP 狀態碼

|Status Code|意義|
|----|----|
|1XX|Information|
|2XX|Success|
|3XX|Redirection|
|4XX|Client Error|
|5XX|Server Error|

### 4. HTTP&HTTPS 的差異

|協定|安全性|說明|
|----|----|----|
|HTTP|不安全|資料是明文傳輸，容易被攔截|
|HTTPS|加密|加了SSL/TLS加密，較為安全|

* SSL&TLS

|名稱|全名||
|----|----|----|
|SSL|Secure Sockets Layer|已淘汰，被TLS取代|
|TLS|Transport Layer Security|現行加密方式|
* TLS做了什麼事:
> 在 SSL/TLS handshake之前，傳輸層上還有一個廣泛使用的協定 'TCP' 有提到一開始建立連線的方法是 Three-way-Handshake。
時序如下:

@startuml
A -> B: SYN
A <- B: SYN-ACK
A -> B: ACK
@enduml

包含三件事情:
1. Client傳送連線請求
2. Server回應確認並同意連線
3. Client傳送最終確認

那在TCP Three-way Handshake 完成之後，如果 A 有希望使用 TLS 加密時就會開始做 TLS Handshake，這包含三件事情:

1. 雙方交換憑證
2. 用非對稱加密傳交換密鑰
3. 之後用對稱加密通訊

@startuml
A -> B: (1) hello
note left
  Highest SSL version
  Cipher supported
  Data Compression Method
  etc.
end note
A <- B: (2) hello
note right
  Selected SSL version
  Selected Cipher
  Selected Data Compression Method
  Certificate
  etc.
end note
A -> A: (3) Validate Certificate
A -> B: (4) Certificate
B -> B: (5) Validate Certificate
A -> B: (6) Key exchange
A -> B: (7) Change Cipher Spec
A -> B: (8) Finished
A <- B: (9) Change Cipher Spec
A <- B: (10) Finished
A <-> B: (11) Encrypted Data Transfer
@enduml

1. A 跟 B 要求要用 TLS 加密，A 先跟 B 說他支援什麼版本跟相關資訊。
2. B 如果有支援的話，就會回傳他選的版本，同時把憑證丟給 A。
3. A 拿到憑證之後，會先要看看是不是合法的，不合法的話會提出警告訊息給使用者。
4. B 也可以要求 A 提出憑證，有的話就回傳給 B。
5. B 拿到憑證之後，一樣要看看是不是合法的，不合法的話會提出警告訊息給使用者。
6. 金鑰交換，隨機產生一組作為對稱式加密使用的密鑰。
7. A 會跟 B 說好接下來要用什麼方法來做資料加密。
8. B 收到訊息並確認這是 A 發出來的。
9. B 也會發訊息通知 A 要用什麼方法做資料加密。
10. A 拿到訊息，也確認完成。
11. 可以開始使用加密資料傳輸了。

* 加密方式

|種類|說明|
|----|----|
|對稱加密|雙方共用一把密鑰|
|非對稱加密|一把公開鑰，一把私密鑰|

## 安全設計準則

### 1. External Systems are Insecure
預設所有來自外部的資料都是不安全的。
實務上來說:
- 所有外部API的輸入都要進行驗證跟消毒。
- 不信任HTTP request headers，例如X-User_ID，要由Server端驗證Session。
- 連接第三方金流服務時，一定要驗證簽章與回乎網址是否正確。

### 2. Minimize Attack Surface Area

只開放必要的介面與功能，減少攻擊點。
實務：
- 只對外開放必要的API
- 管理後臺路徑如admin應限制IP白名單或加二階段認證。
- 使用HTTPS，關閉沒有在使用的port。

### 3. Secure Defaults
預設設定即為安全狀態，讓使用者無需額外設置。
- 使用者預設註冊開啟Email驗證。
- Cookie預設設定為HTTPSonly(443)。
- 密碼需預設強度高的密碼。

### 4. Least Privilege
每個使用者/模組只能存取最小必要權限。
- 前端使用[JWT token](https://ithelp.ithome.com.tw/articles/10225398)時，token裡面只含必要的role，不應該包含敏感資料。
- 前後端每個路徑都要檢查權限，不只是檢查登入狀態。
- 後臺帳號分等級(管理員/編輯者/檢視者)。

### 5. Separation of Duties
不同操作由不同角色執行，防止濫權(分權的概念)
- 一人申請資料刪除，另一人審核。
- CI/CD管理與原始碼審查由不同人員負責。
- Web系統中的角色權限不能疊加，防止出現超級管理員。

### 6. Defense in Depth
多層防護，層層保護。
- HTTPS+身分驗證(JWT)+WAF+[CSRF](https://blog.csdn.net/qq_40558345/article/details/130629334) Token。
- 資料加密(資料庫層)+存取控制(應用層)+日誌審核(監控層)。

### 7. Fail Securely
系統錯誤時不要洩漏資訊，且回到安全狀態。
- 不顯示錯誤堆疊給使用者，只顯示generic error。
- 資料處理錯誤時，應回滾交易或封鎖流程。

### 8. Do not trust Security through Obscurity
不靠把資訊藏起來作為唯一防線。
- 後臺路徑藏起來也要加身分驗證。
- API key不應該藏在前端程式碼中(可能會被反編譯)。

### 9. Simplicity
系統越簡單，越容易管理與安全。
- 前後端溝通設計單純(RESTful API 遵循實例)。
- 不需要的功能盡量不要加，減少維護與風險。
- 權限控管系統清晰易懂。

## OWASP
2025版將會在2025的夏天或是秋初發布。
### 對照表(修改版)： Top 10 - 2017 vs 2021

|2017 Rank|2021 Rank|2021名稱|名稱解釋|預防措施|
|---|---|---|---|---|
|A04<br>A05|**A01**| 權限控制失效 | CSRF、預設權限沒設好<br>例如偷改URL、用自訂API工具繞過檢查、改個參數就能偷看或偷改他人資料、更改cookie拿到權限等等。|- 非公開資料預設拒絕存取<br>- 禁止在網頁顯示網站資料夾功能，避免中繼資料(如.git)及備份資料留在 Web 根目錄<br>- JWT 登出後應要在伺服器端強制失效|
|A03|**A02**| 加密機制失效 | 避免明碼傳輸、淘汰老舊加密演算法與強度不足的金鑰、驗證頻證有效性等等。| - 對系統涉及的資料進行分類，識別哪些是敏感資料，對不同分類採行不同的管控措施。<br>- 非必要不保存敏感資料，不得不存時考慮使用資料記號化(Tokenization)或截斷(Truncation)<br>- 確保所有靜態敏感資料有加密，且使用新版且夠強的加密演算法，並妥善保存金鑰<br>- 使用TLS加密傳輸<br>- 網頁包含敏感資料時禁用Cache|
|A01<br>A07|**A03**| 注入式攻擊 | SQL、OS指令、表達式語言等等的注入都算| - [源碼檢測](https://hackmd.io/@ClaireS/H1BXOjzYel)是有效的發現手段<br>- 把命令跟資料徹底分開；以SQL Injection來說，外界輸入內容依慮使用Dbparameter傳送，或改用EF、ORM技術<br>- 考慮使用白名單在伺服器端驗證輸入資料<br>- 使用LIMIT或TOP限制筆數，萬一受到攻擊時可以減少洩漏資料量|
||**A04**| 不安全設計 | 設計的時候沒想好<br>例如演唱會搶票網站沒加CAPTCHA防機器人驗證 | - 設計階段找專家參與評估及審核<br>- 對關鍵認證、存取控制、商業邏輯與關鍵缺陷進行威脅分析 |
|A06|**A05**| 安全設定缺陷 | 指程式設計及系統架構上的不當設計與設定<br>例如不必要的 Port、帳號或權限、未改掉預設帳號密碼、錯誤訊息曝露程式檔資訊 | - 平台上不要夾帶用不到的功能、套件、工具等等<br>- 落實變更管理，依據資安公告、安全更新、弱點資訊進行安全審核<br>- 採用可分割的應用程式架構，達成管理及安全上的隔離。|
|A09|**A06**| 易受攻擊和已淘汰的組件 | | - 刪除不必要的相依套件、不需要的功能<br> - 盤點客戶端及伺服器端組件及相依套件版本，持續監控與通報<br> - 管控組件來源，一律由官方下載、選擇有數位簽章的更新包|
|A02|**A07**| 認證及驗證機制失效 | 因防禦不足被由其他來源取得帳密名單，允許強度不足的密碼、使用脆弱的忘記密碼或重設密碼機制、密碼以明碼/加密或強度不足的雜湊儲存、缺乏多因素認證、URL 洩漏 Session ID、未正確註銷 Session | - 阻擋脆弱密碼，制定密碼強度要求、定期更換政策<br>- 使用模糊回應避免攻擊者蒐集資訊<br>- 隨機化Session ID，確實註銷登出、閒置、逾時的Session|
||**A08**| 軟體及資料完整性失效 | CDN夾帶惡意程式庫、透過系統自動更新散佈惡意程式 |- 用數位簽章及完整性檢查防止檔案被加料或竄改<br>- 使用軟體供應鏈安全工具確保元件沒有已知弱點<br>- 在CI/CD流程加入必要檢查|
|A10|**A09**| 資安紀錄及監控失效 | 未紀錄登入成功/失敗/重要交易之稽核事件、警告或錯誤未留下日誌或保存的訊息不足、未監控程式或API日誌汁可以活動防毒工具未發揮效果，未能偵測及通告進行中的攻擊，導致種損失。 | - 記錄登入、存取失敗記錄，日誌應包含足夠資訊並保留一定期限供日後鑑識需求<br>- 確保日誌正確編碼，防止日誌/監控系統被注入或攻擊<br>- 重要交易需保留稽核軌跡，防止竄改或刪除(設計只允許新增不能更改的資料表)|
||**A10**|伺服器端請求偽造| Server-Side Request Forgery，攻擊者操縱請求內容，成功克服防火牆、VPN 或存取控管，控制網站發送假的請求給對非預期對象。 |- 轉送請求到後方系統時，步將原始回應直接傳給使用者，已麵讓攻擊者得以推測IP、服務狀態<br>- 停止使用HTTP重新導向|

對照表(原) : OWASP Top 10 — 2017 vs 2021
| 2017 Rank | 2017 名稱 | 2021 Rank | 2021 名稱 | 變化說明 |
| --------- | --------------------------------- | --------- | ------------------------------------------ | ----------------------------------- |
| A1 | Injection | **A3** | Injection | 名次下降，但仍存在。納入 SQL, OS, 等類型 |
| A2 | Broken Authentication | A7 | Identification and Authentication Failures | 名稱擴充，加入 MFA、Session 管理錯誤等 |
| A3 | Sensitive Data Exposure | **A2** | Cryptographic Failures | 重新命名與聚焦密碼學保護失敗，不只是資料外洩 |
| A4 | XML External Entities (XXE) | - | - | 合併到 A5 |
| A5 | Broken Access Control | **A1** | Broken Access Control | 名次上升，實際攻擊風險大幅上升 |
| A6 | Security Misconfiguration | A5 | Security Misconfiguration | 名次提升 |
| A7 | Cross-Site Scripting (XSS) | - | - | 移除為獨立項目，併入 A3\:Injection |
| A8 | Insecure Deserialization | A8 | Software and Data Integrity Failures | 擴充概念，包括 CI/CD 破壞、供應鏈攻擊 |
| A9 | Using Components with Known vulnerabilities | A6 | Vulnerable and Outdated Components | 名稱更具描述性，聚焦過時元件 |
| A10 | Insufficient Logging & Monitoring | A9 | Security Logging and Monitoring Failures | 名次提升，增加事件響應觀念 |

### 2021新增的類別
|編號|名稱|說明|
|----|----|----|
|A4|Insecure Design|強調「設計層級」的風險，像是缺乏威脅建模、安全預設|
|A8|Software and Data Integrity Failures|包含供應鏈攻擊、不安全的 CI/CD、自動更新未驗證簽章等|
|A10|Server-Side Request Forgery| 雖在過去不常見，但近年攻擊上升（例如Cloud Metadata窺探）|

### 主要變化總結分析:
|面向|差異與趨勢|
|----|----|
|名稱更精確|2021版用更「技術精準」的名詞（如 Cryptographic Failures、Integrity Failures）|
|實務導向|根據 500,000 筆+ 真實漏洞資料分析，風險排名更反映實際情況|
|設計 vs 實作|新增「Insecure Design」，提醒安全要從架構階段開始考量|
|加入供應鏈風險|隨著 open source 爆發、CI/CD 普及，2021 新增完整面向處理|
|調整名次|Broken Access Control 升為第一名，反映其高嚴重性與普遍性|
|刪除老問題|CSRF、Unvalidated Redirects 等因防禦技術成熟被移除或併入|

> OWASP 2021 更貼近實務與現代應用環境，加入設計階段與供應鏈風險，刪除過時議題，更強調「整體安全流程與架構」