什么樣的登錄方式才是最安全的？

一、基礎協議：HTTP與HTTPS

HTTP協議

HTTPS協議

二、常見Web攻擊與防御

2.1 XSS

常見攻擊手段

針對XSS 攻擊竊取 Cookie

2.2 CSRF

CSRF攻擊的核心特點

與XSS的區別

常見防御措施

三、疑問解答

四、登錄方式演變

4.1 方案一🐶狗都不用

介紹

問題

4.2 方案二🐶狗都不用

介紹

問題

4.3 方案三 🐕小狗用一下

問題

總結：

4.4 方案四🐶

普通Token實現

JWT（JSON Web Token）

關鍵差異對比

使用建議

相交于session機制

需注意的例外情況

在Web開發中，用戶認證是保障系統安全的第一道防線。本文將系統性地介紹HTTP/HTTPS、Cookie、Session、Token等核心概念，分析常見攻擊手段（XSS/CSRF），并對比不同認證方案的優劣，幫助開發者構建安全的認證體系。

在回答這個問題前，我想先通過幾個問題，來建立起登錄相關的基本概念，再進行回答。

一、基礎協議：HTTP與HTTPS

HTTP協議

??明文傳輸??：請求和響應報文均為明文形式
??無狀態??：每次請求獨立，服務器不保留連接信息
??端口??：默認使用80端口
??風險??：易受中間人攻擊，敏感信息可能被竊取

HTTPS協議

??加密傳輸??：在HTTP基礎上加入SSL/TLS加密層
??身份驗證??：通過CA證書驗證服務器真實性
??端口??：默認使用443端口
??優勢??：
- 防止數據竊聽（傳輸加密）
- 防止數據篡改（完整性校驗）
- 防止身份冒充（證書認證）

雖然HTTPS解決了傳輸安全問題，但無法防御XSS、CSRF等攻擊手段。

二、常見Web攻擊與防御

2.1 XSS

XSS（跨站腳本攻擊，Cross-Site Scripting）是一種常見的Web安全漏洞，攻擊者通過在網頁中注入惡意腳本代碼，當其他用戶訪問該頁面時，這些腳本會在用戶瀏覽器中執行，從而達到竊取信息或進行其他惡意操作的目的。

常見攻擊手段

盜取用戶Cookie和會話信息
偽造用戶身份執行操作（如轉賬、發帖等）
植入惡意軟件或釣魚內容
發起DDoS攻擊

針對XSS 攻擊竊取 Cookie

攻擊方式：黑客注入惡意 JavaScript（如 <script>alert(document.cookie)</script>），竊取 HttpOnly 未設置的 Cookie。
防御措施：
- 設置 HttpOnly 屬性，禁止 JavaScript 訪問 Cookie。
- 啟用 Secure 屬性，強制 HTTPS 傳輸。
- 使用 Content-Security-Policy (CSP) 防止 XSS。

2.2 CSRF

CSRF（Cross-Site Request Forgery，跨站請求偽造）是一種利用用戶已登錄狀態，誘使用戶在不知情的情況下向目標網站發送惡意請求的網絡攻擊手段。攻擊者通過偽造用戶請求，冒充用戶執行非本意的操作（如轉賬、修改密碼等）。

CSRF攻擊的核心特點

??利用信任機制??：依賴網站對用戶瀏覽器的信任（如Cookie/Session認證）
??無需竊取憑證??：攻擊者無需獲取用戶密碼或Cookie內容
??隱蔽性強??：攻擊過程用戶無感知，通常只需點擊鏈接或訪問頁面

與XSS的區別

特性	CSRF	XSS
攻擊目標	利用網站對用戶的信任	利用用戶對網站的信任
數據獲取	不直接竊取數據	直接竊取Cookie/敏感信息
實現方式	偽造請求（如<img>標簽自動加載）	注入惡意腳本執行
防御重點	請求來源驗證	輸入輸出過濾

常見防御措施

??CSRF Token??：服務器生成隨機Token，嵌入表單或請求頭

<form action="/transfer" method="POST"> <input type="hidden" name="csrf_token" value="a1b2c3d4"> <!-- 其他表單字段 --> 
</form>

??SameSite Cookie??：設置SameSite=Strict限制跨站Cookie發送
??驗證Referer??：檢查請求來源域名是否合法
??敏感操作二次驗證??：如短信驗證碼、密碼確認等

根據OWASP統計，CSRF在Web安全威脅中長期位列前十，正確實施Token驗證可防范99%的CSRF攻擊

三、疑問解答

問題：通過瀏覽器的控制臺能看到當前請求的路徑以及輸入的賬號密碼等信息，這些信息難道不會被黑客直接看到嗎？

控制臺信息需通過物理接觸設備或植入惡意腳本才有可能獲取，普通網絡攻擊無法直接利用。

通過XSS漏洞注入腳本可竊取控制臺數據
特定瀏覽器漏洞可能繞過CSP策略（如Chrome CVE-2020-6519）
未啟用HTTPS時網絡嗅探可獲取明文數據
惡意WiFi熱點可能劫持HTTP連接

那么為什么說cookie和session不一定安全，不都是用https加密了嗎

即使使用了 HTTPS 加密傳輸，Cookie 和 Session 仍然存在安全風險，因為 HTTPS 僅能保護傳輸過程的相對安全，而無法完全防御其他攻擊手段。以下是具體原因分析：

1. HTTPS 的作用與局限

HTTPS（SSL/TLS）主要解決：

傳輸加密：防止數據在傳輸過程中被竊聽（如中間人攻擊）。
身份驗證：確保客戶端連接的是真實的服務器（通過 CA 證書）。

但 HTTPS 無法防御以下攻擊：

XSS（跨站腳本攻擊）：竊取 Cookie 或 Session ID。
CSRF（跨站請求偽造）：利用瀏覽器自動攜帶 Cookie 的特性發起惡意請求。
Session 劫持：通過竊取 Session ID 冒充用戶。
Cookie 泄露：服務器或客戶端存儲不當導致泄露。

2. Cookie 的安全風險（即使使用 HTTPS）

(1) XSS 攻擊竊取 Cookie

攻擊方式：黑客注入惡意 JavaScript（如 <script>alert(document.cookie)</script>），竊取 HttpOnly 未設置的 Cookie。
防御措施：
- 設置 HttpOnly 屬性，禁止 JavaScript 訪問 Cookie。
- 啟用 Secure 屬性，強制 HTTPS 傳輸。
- 使用 Content-Security-Policy (CSP) 防止 XSS。

(2) CSRF 攻擊（跨站請求偽造）

攻擊方式：誘導用戶點擊惡意鏈接，瀏覽器自動攜帶 Cookie 發起請求（如轉賬）。
防御措施：
- 設置 SameSite 屬性（Strict 或 Lax），限制跨站請求。
- 使用 CSRF Token（服務端驗證）。

(3) Cookie 泄露

攻擊方式：
- 服務器日志、數據庫泄露未加密的 Cookie。
- 客戶端存儲的 Cookie 被惡意軟件讀取。
防御措施：
- 加密敏感 Cookie 數據。
- 定期更換 Session ID。

3. Session 的安全風險（即使使用 HTTPS）

(1) Session 劫持（Session Hijacking）

攻擊方式：
- 通過 XSS 竊取 Session ID。
- 網絡嗅探（如公共 Wi-Fi）獲取未加密的 Session ID（如果 HTTPS 配置不當）。
防御措施：
- 綁定 Session 到用戶 IP 或 User-Agent（但可能影響用戶體驗）。
- 使用短 Session 有效期 + 自動注銷。

(2) Session 固定（Session Fixation）

攻擊方式：
- 攻擊者預先設置 Session ID（如 ?PHPSESSID=123），誘導用戶登錄后劫持會話。
防御措施：
- 登錄后生成新 Session ID（如 session_regenerate_id()）。
- 禁用 URL 傳遞 Session ID。

(3) 服務器端 Session 存儲泄露

攻擊方式：
- 服務器文件或數據庫被入侵，導致 Session 數據泄露。
防御措施：
- 加密存儲 Session 數據。
- 使用 Redis 等內存數據庫，而非文件存儲。

4. 為什么 JWT 相對更安全？

JWT（JSON Web Token）的安全性依賴于簽名機制，但同樣需要配合 HTTPS 使用：

防篡改：簽名確保數據未被修改（如 HMAC 或 RSA）。
無狀態：服務端無需存儲 Session，降低數據庫泄露風險。
但仍需防范：
- Token 泄露（XSS 攻擊）。
- 弱密鑰（如 123456）。
- 過期時間過長（需設置短 exp）。

四、登錄方式演變

問題：

希望頁面的相關請求都要維持一個登錄狀態？怎么做？

換句話說，每次請求都需要知道當前用戶是不是登錄的狀態，怎么實現？

4.1 方案一🐶狗都不用

沒有cookie、session、token這些技術

介紹

如果沒有cookie、session、token這些技術的話，那么這個問題將會變得非常麻煩。

首先，用戶在登錄頁面，帶著用戶名密碼傳遞給后端。后端校驗通過后，成功響應。

此后，用戶再在任何頁面發起后端請求時，都要攜帶這個用戶名密碼信息，等于說每個接口后端也都需要校驗用戶名密碼。

問題

這樣做有什么問題呢？

安全性極低 （0%）

每次請求明文傳輸密碼，易被攔截（如中間人攻擊），即使使用HTTPS也無法避免密碼在客戶端存儲的風險。

密碼長期暴露在請求中，泄露概率大幅增加。
性能開銷大

每次請求需查詢數據庫校驗密碼，高頻請求下數據庫壓力劇增，而Session/Token只需首次登錄時校驗。
用戶體驗差

用戶需手動輸入或客戶端持久化存儲密碼，前者操作繁瑣，后者不安全。
無法實現關鍵功能

會話管理：無法主動踢人、強制下線或限制并發登錄

短期授權：如Token可設置過期時間，而密碼無法動態失效

4.2 方案二🐶狗都不用

單cookie。即僅依賴Cookie存儲用戶信息并維持登錄狀態。

介紹

Cookie是服務器發送到用戶瀏覽器并保存在本地的一小塊數據（通常不超過4KB），會在瀏覽器下次向同一服務器發起請求時被攜帶并發送到服務器上。

首先，用戶登錄時通過用戶名密碼發起請求，后端校驗通過后，通過HTTP響應頭中的Set-Cookie字段發送Cookie到客戶端（這個cookie記錄了用戶信息，例如可以是用戶名）。

前端收到響應報文后，會將這個cookie保存起來，此后每次請求都攜帶這個cookie。后端只要能解析到這個cookie。就認為是已登錄的。

Cookie的組成

一個完整的Cookie包含以下屬性

名稱(Name)和值(Value)：存儲的實際數據

Expires/Max-Age：設置過期時間（不設置則為會話Cookie，關閉瀏覽器即失效）

Path：定義可訪問該Cookie的網站路徑

Domain：指定可訪問該Cookie的域名

Secure：僅通過HTTPS協議傳輸

HttpOnly：防止JavaScript訪問，增強安全性

Cookie的類型

會話Cookie：臨時性，存儲在內存中，瀏覽器關閉后刪除

持久Cookie：設置過期時間，存儲在硬盤上，在服務器設置的過期時間前一直有效

問題

相較于方案一，每次通過用戶名密碼，這樣的好處僅僅是

密碼沒有明文傳遞
不需要每次手動輸入用戶名密碼

但是問題依舊嚴重。

安全性極低（1%）

若Cookie直接存儲用戶名、密碼或未加密的用戶數據，一旦被竊取（如XSS攻擊、網絡嗅探），攻擊者可輕易偽造用戶身份

Cookie默認隨請求自動發送，攻擊者可誘導用戶點擊惡意鏈接，利用已登錄狀態發起偽造請求（如轉賬操作）

Cookie若未設置HttpOnly和Secure屬性，可能被JavaScript讀取或通過非HTTPS傳輸，導致信息泄露。

Cooike有容量限制：最大4kb。

相比較方案一：僅僅是沒有明文傳遞，對于正兒八經的的黑客，這沒有一點優勢，甚至于熟悉cookie攻擊的黑客來講，安全性更差。
無法實現關鍵功能

會話管理：無法主動踢人、強制下線或限制并發登錄

短期授權：無法主動使Cookie失效，如用戶修改密碼后仍需等待Cookie過期，而Session或Token可通過服務端黑名單即時撤銷。
跨域限制

Cookie默認僅在同域名下發送，難以支持跨域單點登錄。
客戶端依賴

瀏覽器禁用Cookie時功能完全失效。

4.3 方案三 🐕小狗用一下

采用cookie和session機制。

客戶端首次請求時，服務器創建Session并生成唯一Session ID。（Session是一種服務器端的會話管理機制，服務器為每個客戶端用戶創建一個唯一的Session對象來存儲會話數據）
服務器通過Set-Cookie將Session ID發送給客戶端（通常名為JSESSIONID或PHPSESSID）
Session ID的傳遞方式：
1. Cookie（最常見方式）
2. URL重寫：當Cookie被禁用時，將Session ID附加在URL后
3. 隱藏表單字段：通過表單隱藏字段傳遞
客戶端保存Session ID并在后續請求中攜帶
服務器通過Session ID查找對應的Session數據

注意：整個過程我們只需要往session中存儲數據，處理數據即可。其他的像設置cookie這些瀏覽器就幫我們完成了。

Session的生命周期

創建：用戶首次訪問時

維護：通過Session ID保持會話狀態

銷毀：可通過以下方式：

用戶主動注銷

Session超時（默認通常30分鐘）

服務器主動銷毀

Cookie與Session的比較

特性 Cookie Session
存儲位置 客戶端服務器端
安全性 較低，易被篡改較高，數據在服務器端
存儲容量 有限（約4KB）無嚴格限制
生命周期 可長期保存通常較短
性能影響 幾乎無影響占用服務器資源
數據類型 僅文本任意類型

特性	Cookie	Session
存儲位置	客戶端	服務器端
安全性	較低，易被篡改	較高，數據在服務器端
存儲容量	有限（約4KB）	無嚴格限制
生命周期	可長期保存	通常較短
性能影響	幾乎無影響	占用服務器資源
數據類型	僅文本	任意類型

問題

安全性（??）

Cookie安全問題：
- 竊取：需要設置HttpOnly和Secure標志，否則XSS攻擊可能獲取Cookie
- 偽造：修改客戶端Cookie值
- CSRF攻擊：利用用戶已認證狀態發起惡意請求
Session安全問題：
- 會話劫持：獲取有效Session ID
- 會話固定：強制用戶使用攻擊者提供的Session ID
- 防護措施：
  - 使用安全的Session ID生成算法
  - 用戶登錄后更換Session ID
  - 設置合理的超時時間
服務器資源消耗
- session占用服務器內存，用戶量大會導致內存壓力
- 可能引發內存溢出，特別是Session數據復雜時
- 需要定期清理過期Session，增加服務器負擔
分布式環境問題
- 多服務器環境下需要Session共享機制，處理起來就比較復雜了
- Session同步可能成為性能瓶頸
- 需要額外配置如Redis等中間件來共享Session
依賴性問題
- 默認依賴Cookie傳遞Session ID，當Cookie被禁用時需要URL重寫
- URL重寫方式安全性較低且使用不便

總結：

雖然這里我標記的兩顆星，在應對一些簡單的場景時，還是可以用的。但是多集群部署、分布式，甚至高并發場景，對安全性要求更高，那么就不推薦使用了，而且用起來也非常復雜。

4.4 方案四🐶

Token（令牌）

Token是一個廣義概念，指任何形式的身份驗證令牌，用于在客戶端和服務器之間傳遞身份驗證和授權信息。Token可以有多種實現方式，如基于會話的Token、基于時間的Token等。

普通Token實現

通常是一個隨機生成的字符串（如UUID），存儲在服務器端（如Redis），需要查詢驗證。

JWT（JSON Web Token）

JWT是一種具體的Token實現方式，遵循RFC 7519標準。它是自包含的，意味著包含了所有必要信息（包括用戶信息和簽名），無需查詢數據庫即可驗證其有效性。JWT由三部分組成，用點號(.)分隔

Header：聲明類型和算法（如HS256）
Payload：包含聲明（用戶信息等）
Signature：對前兩部分的簽名，防止篡改

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

說明：

包含關系：JWT是Token的一種特殊形式，所有JWT都是Token，但并非所有Token都是JWT。

信息承載方式：

普通Token：通常只是一個隨機字符串，本身不包含信息，需要服務器查詢數據庫驗證。

JWT：自身包含認證信息（JSON格式），通過簽名保證完整性，無需服務器存儲

驗證機制：

普通Token：服務器需要查詢數據庫驗證Token有效性

JWT：服務器直接通過密鑰驗證簽名，無需查詢數據庫（除非使用黑名單機制）

應用場景

普通Token適用場景:

需要即時撤銷Token的情況

對安全性要求極高，需要完全控制Token生命周期的場景

JWT適用場景：

無狀態認證（如RESTful API）

跨域認證（如單點登錄）

微服務架構中的服務間認證

關鍵差異對比

特性	普通Token	JWT
服務器存儲	需要	不需要
驗證方式	查數據庫	驗證簽名
信息包含	無用戶信息	包含用戶信息
吊銷機制	可即時吊銷	只能等待過期
跨域支持	有限	優秀
性能影響	數據庫I/O開銷	加密/解密開銷
適用場景	傳統Web應用	分布式系統/API

使用建議

選擇普通Token：當需要即時吊銷能力、對安全性要求極高或系統規模較小時
選擇JWT：在分布式系統、無狀態API、前后端分離或需要跨域認證的場景
混合使用：某些場景可結合兩者優勢，如使用JWT作為短期Access Token，配合可吊銷的Refresh Token

相交于session機制

Token相比Session在某些方面確實具有更高的安全性。

防CSRF攻擊能力 Token機制天然免疫CSRF（跨站請求偽造）攻擊。

因為Token通常放在HTTP頭部的Authorization字段中，而非Cookie，攻擊者無法通過偽造鏈接誘導用戶發送攜帶Token的請求。

而Session依賴Cookie傳遞Session ID，容易遭受CSRF攻擊。
無狀態架構優勢 Token無需服務器存儲會話狀態，避免了Session面臨的會話劫持風險（如Session ID被竊取后可直接冒充用戶）。即使Token泄露，也可通過短期有效期和黑名單機制降低風險。
分布式場景安全性 在微服務架構中，Token無需Session同步機制，避免了集中式Session存儲的單點故障風險。
傳輸安全性 Token可通過HTTPS+加密存儲（如HttpOnly Cookie）雙重保護，而Session ID默認通過Cookie傳輸，若未設置Secure標志可能被明文截獲。