@hoag/blog

Hiểu đúng về CSRF và cách phòng chống hiệu quả

Hoang Vu,•5 min read
Security

Ngày 25 tháng 3, 2026

CSRF (Cross-Site Request Forgery) là kiểu tấn công lừa trình duyệt của user đang đăng nhập gửi request thay đổi trạng thái tới hệ thống mà user không chủ đích thực hiện.

Khác XSS, attacker không nhất thiết phải chạy script trong origin của bạn. Họ lợi dụng việc browser tự động đính kèm cookie phiên.

Loading CSRF remotion demos...

1. Luồng CSRF điển hình

Một kịch bản thường gặp:

  1. User đang đăng nhập vào ứng dụng mục tiêu.
  2. Attacker tạo trang/link độc hại.
  3. User truy cập trang độc hại khi phiên đăng nhập còn hiệu lực.
  4. Browser gửi request sang ứng dụng mục tiêu kèm cookie phiên.
  5. Server xử lý request nếu không có cơ chế chống CSRF.

Từ góc nhìn backend, request trông rất giống hành vi hợp lệ của user thật.

Đi sâu hơn: vì sao browser khiến CSRF khả thi

Gốc vấn đề là "ambient authority": browser tự gắn cookie phiên vào request. Nếu server chỉ dựa vào cookie để kết luận request hợp lệ mà không verify ý định người dùng, attacker có thể lợi dụng điều này để tạo side effect trái phép.

Nói ngắn gọn: có xác thực, nhưng không có bằng chứng về chủ đích hành động.

CSRF ATTACK FLOW

1. Victim authenticated
2. Session cookie active
3. Victim opens attacker page
4. Forged request sent
5. Server may accept action

2. Vì sao CSRF nguy hiểm

  1. Khai thác trực tiếp phiên đã xác thực.
  2. Nạn nhân thường không biết hành động đã diễn ra.
  3. Log có thể vẫn hiển thị user/session hợp lệ, gây khó điều tra.

Tác động thường gặp: đổi email, đổi mật khẩu, chỉnh quyền, tạo giao dịch trái phép.

Trong vận hành thực tế, CSRF nguy hiểm vì thường chạy âm thầm, khó phân biệt với traffic thật nếu telemetry không được thiết kế tốt.

3. Cơ chế phòng thủ chính: anti-CSRF token

Với các endpoint thay đổi trạng thái, yêu cầu token chống CSRF và verify ở server.

Pattern cơ bản:

  1. Server phát token theo session hoặc theo request.
  2. Client gửi token qua hidden field hoặc custom header.
  3. Server so khớp token trước khi xử lý mutation.
  4. Thiếu/sai token thì reject (403).

Token nên:

  • khó đoán,
  • có vòng đời ngắn khi phù hợp,
  • rotate/scope theo mức độ nhạy cảm của action.

Chi tiết triển khai dễ bị bỏ sót

CSRF token phải được kiểm tra ở mọi endpoint mutation, kể cả route cũ ít dùng hoặc panel nội bộ. Một endpoint thiếu kiểm tra có thể phá hỏng toàn bộ lớp phòng thủ.

CSRF TOKEN VALIDATION

Server issues CSRF token
Client sends token in mutation request
Server validates token against session
Reject if missing / mismatch

4. SameSite cookie là lớp bảo vệ rất quan trọng

Cấu hình cookie đúng cách:

  1. SameSite=Lax thường là default tốt cho nhiều app.
  2. SameSite=Strict an toàn hơn nhưng có thể ảnh hưởng UX một số flow.
  3. SameSite=None chỉ dùng khi thật sự cần cross-site và phải đi cùng Secure.

Đồng thời luôn dùng:

  • Secure cho HTTPS,
  • HttpOnly cho cookie phiên.

SameSite giúp giảm đáng kể khả năng cookie bị gửi trong bối cảnh cross-site.

Chọn SameSite theo ngữ cảnh sản phẩm

  1. Lax: cân bằng tốt cho đa số ứng dụng.
  2. Strict: mạnh hơn nhưng có thể ảnh hưởng flow điều hướng từ ngoài vào.
  3. None: chỉ dùng khi thật sự cần cross-site và luôn đi kèm Secure.

SameSite là lớp quan trọng, nhưng không thay thế hoàn toàn CSRF token.

CSRF COOKIE + POLICY SHIELD

SameSite=Lax/Strict
Secure cookie
HttpOnly session
Origin/Referer check

5. Kỷ luật HTTP method

Không dùng GET cho hành động thay đổi dữ liệu.

Lý do:

  1. GET dễ bị kích hoạt qua link hoặc thẻ nhúng.
  2. URL GET có thể vào history/cache/share.
  3. GET nên giữ semantic idempotent.

Dùng POST/PUT/PATCH/DELETE cho mutation và bắt buộc verify CSRF ở các route này.

Việc tuân thủ đúng semantic method cũng giúp hệ thống dễ quan sát, dễ review và dễ điều tra hơn khi có sự cố.

6. Bổ sung lớp kiểm tra phía server

Defense-in-depth thường gồm:

  1. kiểm tra Origin và/hoặc Referer khi phù hợp,
  2. phát hiện mẫu mutation bất thường từ nguồn cross-site,
  3. cấu hình CORS chặt chẽ cho API,
  4. step-up auth cho hành động rủi ro cao.

Không có một kỹ thuật đơn lẻ đủ an toàn cho mọi kiến trúc.

Hardening theo mức rủi ro

Với hành động nhạy cảm cao (đổi email, reset 2FA, thay đổi thông tin thanh toán):

  1. yêu cầu re-auth hoặc step-up verification,
  2. bổ sung token chống replay,
  3. giám sát bất thường theo origin/user-agent,
  4. log event bảo mật có cấu trúc để điều tra nhanh.

7. Pattern triển khai thực tế với Next.js

Với ứng dụng auth theo cookie:

  1. phát CSRF token khi bootstrap session/form,
  2. gửi token bằng custom header ở mutation request,
  3. verify token tại API route hoặc server action,
  4. reject mismatch và log security event,
  5. kết hợp cùng chiến lược SameSite cookie.

Nếu API dùng Bearer token qua Authorization header (không dựa vào cookie tự động), rủi ro CSRF thường thấp hơn nhưng vẫn phải threat-model rõ ràng.

Nếu hệ thống chạy song song cookie auth và bearer auth, cần document rõ boundary. Kiến trúc mixed-mode là nơi assumptions về CSRF dễ sai nhất.

8. Checklist nhanh

  1. Tuyệt đối không mutate state bằng GET.
  2. Bắt buộc CSRF token cho toàn bộ endpoint mutation.
  3. Cấu hình SameSite, Secure, HttpOnly đúng chuẩn.
  4. Verify Origin/Referer khi khả thi.
  5. Siết chặt hơn cho flow rủi ro cao.
  6. Theo dõi spike request bất thường và CSRF validation fail.

9. Kết luận

CSRF là bài toán nhầm lẫn niềm tin: server tin vào cookie mà browser tự gửi.

Muốn chặn hiệu quả cần kết hợp nhiều lớp:

  • CSRF token,
  • cookie attributes chuẩn,
  • kỷ luật HTTP method,
  • kiểm tra server-side bổ sung.

Khi làm đúng theo lớp phòng thủ, CSRF sẽ từ rủi ro ngầm thành vùng kiểm soát bảo mật rõ ràng.

Mục tiêu thực tế không phải "thêm một tính năng chống CSRF", mà là thiết kế nhiều lớp sao cho mỗi lớp đều làm giảm xác suất tấn công thành công.

2026 © @hoag/blog.