XSRF/CSRF trong an ninh mạng: Cơ chế, Token bảo vệ và phòng chống

XSRF/CSRF là gì?

CSRF (Cross-Site Request Forgery) - còn gọi **XSRF**, **Sea Surf**, **Session Riding**, **Hostile Linking** - là tấn công ép buộc người dùng đã xác thực (logged-in) thực hiện hành động không mong muốn trên ứng dụng web mà họ đang đăng nhập. Kẻ tấn công khai thác niềm tin của ứng dụng vào trình duyệt của nạn nhân.

1. Cơ chế tấn công CSRF

1. Nạn nhân đăng nhập vào `bank.com` (có session cookie hợp lệ).
2. Kẻ tấn công dụ nạn nhân truy cập `evil.com` (email, tin nhắn, quảng cáo...).
3. `evil.com` chứa form/JS tự động submit request tới `bank.com/transfer` (ví dụ: chuyển tiền).
4. Trình duyệt **tự động gửi cookie session** của `bank.com` kèm request (vì same-domain).
5. Server `bank.com` thấy request hợp lệ (cookie đúng) → thực hiện chuyển tiền.
6. Nạn nhân không hay biết cho đến khi kiểm tra tài khoản.

2. Đặc điểm quan trọng

• **Chỉ tác động thay đổi trạng thái (State-changing):** Chuyển tiền, đổi mật khẩu, đổi email, xóa tài khoản, mua hàng. KHÔNG có ích cho việc chỉ đọc dữ liệu (GET) vì response về phía nạn nhân, không phải kẻ tấn công.
• **Khाई thác cookie authentication:** Cookie-based auth tự động gửi kèm request cross-origin.
• **Không cần đánh cắp credential:** Chỉ cần nạn nhân đang login.

3. CSRF Token - Cơ chế bảo vệ chuẩn

CSRF Token (XSRF Token) là giá trị **bí mật, duy nhất, không thể đoán trước** do server sinh ra cho mỗi session/form.

Quy trình:

1. User request trang form (GET). Server sinh token ngẫu nhiên (crypto-random), lưu vào session, nhúng vào form ẩn `` hoặc header `X-CSRF-Token`.
2. User submit form (POST). Token được gửi kèm.
3. Server so sánh token từ request với token trong session. Khớp → chấp nhận. Không khớp/thiếu → từ chối (403).

Thuộc tính token tốt:

• Entropy cao (≥128 bit).
• Gắn liền với session/user.
• Hết hạn sau một thời gian / một lần dùng (per-request token an toàn hơn).
• Truyền qua POST body hoặc Custom Header (không qua URL/GET).

4. SameSite Cookie Attribute - Dòng phòng thủ hiện đại

5. Các biện pháp bảo vệ bổ sung (Defense in Depth)

• Custom Request Header: Yêu cầu header `X-Requested-With: XMLHttpRequest` hoặc custom header cho AJAX/Fetch. Browser không cho site khác set custom header cross-origin (CORS preflight).
• Double Submit Cookie: Token trong cookie + token trong header/body. So sánh hai giá trị. Không cần lưu session server-side (stateless).
• Re-authentication / MFA: Yêu cầu nhập lại mật khẩu/OTP cho hành động nhạy cảm (đổi pass, chuyển tiền lớn).
• Check Origin / Referer Header: Kiểm tra `Origin` hoặc `Referer` header khớp domain tin cậy. Không tin cậy tuyệt đối (có thể spoof/firewall strip).
• CORS Policy chặt chẽ: Không `Access-Control-Allow-Origin: *` cho endpoint state-changing. Không `Access-Control-Allow-Credentials: true` với origin wildcard.

6. Ví dụ tấn công CSRF thực tế

• Đổi email tài khoản → reset password → chiếm tài khoản.
• Chuyển tiền ngân hàng / thanh toán.
• Thêm admin user mới vào CMS.
• Tắt 2FA / bảo mật.
• Đăng bài spam / xấu tên qua tài khoản nạn nhân.

7. Kiểm tra CSRF (Testing)

• Burp Suite: CSRF PoC Generator (Engagement tools > Generate CSRF PoC).
• OWASP ZAP: Active scan CSRF.
• Manual: Tạo trang HTML tự submit form đến endpoint target, test với user đã login.

8. XSRF vs CSRF

Hoàn toàn giống nhau. XSRF chỉ là cách viết tắt khác (Cross-Site Request Forgery -> X-SRF).术语 CSRF phổ biến hơn (OWASP, MITRE).

Tóm lại: CSRF là lỗ hổng nghiêm trọng nhưng dễ phòng chống. **Kết hợp SameSite=Lax (mặc định trình duyệt hiện đại) + CSRF Token cho các endpoint nhạy cảm + Re-auth cho hành động quan trọng** là chiến lược tốt nhất. Luôn test CSRF trong quy trình SDLC.