Hiểu Rõ CSRF và CSRF Token: Tại Sao Hacker Không Thể Đánh Cắp Qua Proxy?

⏳ Tóm tắt cho người bận rộn (TL;DR)

• Bản chất CSRF: Trình duyệt có thói quen tự động đính kèm Cookie vào mọi request. Hacker dụ bạn vào web của chúng, web này ngầm gửi lệnh lên Ngân hàng của bạn, và trình duyệt vô tình đính kèm Cookie (chữ ký) của bạn đi theo.
• Vai trò của CSRF Token: Là một mã ngẫu nhiên phải được đính kèm thủ công (qua Form hoặc Header). Trình duyệt không tự động gửi cái này.
• Tại sao Hacker không cướp được Token?
  1. Trình duyệt có luật Same-Origin Policy (SOP): Code trên web hacker KHÔNG THỂ đọc được nội dung trên web ngân hàng để cào lấy Token.
  2. Hacker không thể dùng Proxy để bắt gói tin của bạn, vì đường truyền đi thẳng từ máy bạn lên Ngân hàng và đã được mã hóa HTTPS.

---

📖 BÀI VIẾT CHI TIẾT

1. Hiểu nhanh CSRF qua ví dụ "Giao dịch ngân hàng"

Hãy tưởng tượng bạn đăng nhập vào trang ngân hàng nganhang.com:

• Session Cookie giống như chữ ký / dấu vân tay của bạn được lưu tại quầy làm việc. Khi bạn truy cập nganhang.com, trình duyệt tự động trình dấu vân tay này để ngân hàng biết bạn đã đăng nhập.
• Kẻ xấu (Hacker) tạo một trang web độc hại web-doc-hai.com có chứa một nút ẩn gửi lệnh: "Chuyển 10 triệu cho Hacker".
• Cuộc tấn công: Khi bạn vô tình truy cập web-doc-hai.com, trang này tự động gửi yêu cầu chuyển tiền đến nganhang.com. Trình duyệt tự động đính kèm Session Cookie của bạn vào yêu cầu đó. Phía ngân hàng thấy chữ ký đúng nên thực hiện lệnh chuyển tiền ngay lập tức.

2. CSRF Token là vị cứu tinh như thế nào?

Để chặn đòn tấn công trên, hệ thống sử dụng thêm CSRF Token:

• CSRF Token giống như mã OTP ngẫu nhiên chỉ xuất hiện ẩn trên giao diện trang chính chủ nganhang.com.
• Khi gửi lệnh chuyển tiền, server yêu cầu gửi kèm CẢ HAI:
  1. Session Cookie (Xác nhận bạn là ai - gửi tự động).
  2. CSRF Token (Xác nhận hành vi này do chính bạn thao tác từ giao diện chính chủ - phải đính kèm thủ công qua mã JS/HTML).

So sánh nhanh:

3. Tại sao Hacker có Proxy lại không bắt được CSRF Token trên Header?

Nhiều bạn thắc mắc: "CSRF Token nằm trên source code, gửi qua Header. Vậy Hacker rải Proxy bắt Header là xong đúng không?"

Đây là sự hiểu lầm phổ biến giữa việc Hacker bắt request của chính hacker và Hacker bắt request của nạn nhân.

Trong đòn tấn công CSRF:

• Hacker ngồi ở máy A.
• Bạn (Nạn nhân) ngồi ở máy B.
• Khi bạn dính bẫy, request gửi TRỰC TIẾP từ máy B lên Server Ngân hàng.

Nếu Hacker cài Proxy (Burp Suite, Charles...), chúng chỉ bắt được gói tin đi qua máy A. Chúng hoàn toàn mù trước đường truyền từ máy B của bạn. Hacker không thể dùng trang web độc hại để "cào" Token của bạn vì 2 rào cản:

Lớp chắn 1: Same-Origin Policy (SOP) của trình duyệt

Luật thép của trình duyệt: Code JS trên domain web-doc-hai.com KHÔNG BAO GIỜ được phép đọc nội dung trả về từ nganhang.com. Dù trang của Hacker có cố tình gửi request lấy trang chủ ngân hàng về, thì khi server trả về HTML có chứa CSRF Token, trình duyệt sẽ lập tức chặn lại. JS độc hại bị "bịt mắt", không lấy được token để đính kèm.

Lớp chắn 2: Mã hóa HTTPS

Kể cả khi Hacker thực hiện tấn công Man-in-the-Middle (ví dụ: phát Wi-Fi giả mạo ở quán cafe) để nghe lén gói tin của bạn, chúng cũng sẽ bó tay nếu web dùng HTTPS. Toàn bộ HTTP Header (chứa CSRF Token) đã bị mã hóa thành những chuỗi ký tự vô nghĩa trước khi rời khỏi máy bạn.

🎯 Tổng kết

CSRF Token an toàn không phải vì nó là một chuỗi mã hóa siêu việt, mà vì nó dựa trên sự tin cậy của trình duyệt (SOP) và bảo mật đường truyền (HTTPS). Nếu ứng dụng của bạn chưa áp dụng CSRF Token (hoặc thuộc tính SameSite cho Cookie), đây là lúc bạn nên cập nhật ngay cho dự án của mình!