Bài trước tôi đã giới thiệu với các bạn về CSRF và Những hiểu về biết chung
Dựa trên nguyên tắc của CSRF “lừa trình duyệt của người dùng (hoặc người dùng) gửi các câu lệnh HTTP“, các kĩ thuật phòng tránh sẽ tập trung vào việc tìm cách phân biệt và hạn chế các câu lệnh giả mạo.
Đối với người sử dụng internet
Để phòng tránh trở thành nạn nhân của các cuộc tấn công CSRF, người dùng internet nên thực hiện một số lưu ý sau
- Nên thoát khỏi các website quan trọng: Tài khoản ngân hàng, thanh toán trực tuyến, các mạng xã hội, gmail, yahoo… khi đã thực hiện xong giao dịch hay các công việc cần làm. (Check email, checkin…)
- Không nên click vào các đường dẫn mà bạn nhận được qua email, qua facebook … Khi bạn đưa chuột qua 1 đường dẫn, phía dưới bên trái của trình duyệt thường có địa chỉ website đích, bạn nên lưu ý để đến đúng trang mình muốn.
- Không lưu các thông tin về mật khẩu tại trình duyệt của mình (không nên chọn các phương thức “đăng nhập lần sau”, “lưu mật khẩu” …
- Trong quá trình thực hiện giao dịch hay vào các website quan trọng không nên vào các website khác, có thể chứa các mã khai thác của kẻ tấn công.
Đối với các website
Có nhiều lời khuyến cáo được đưa ra, tuy nhiên cho đến nay vẫn chưa có biện pháp nào có thể phòng chống triệt để CSRF. Sau đây là một vài kĩ thuật sử dụng.
Hạn chế thời gian hiệu lực của SESSION
- Tùy theo ngôn ngữ hoặc web server dc sử dụng mà cách thực hiện có thể rất khác nhau. Với PHP, thông số “session.gc_maxlifetime” trong file php.ini qui định thời gian hiệu lực của session.
Nếu lập trình viên sử dụng ngôn ngữ k hỗ trợ chức năng này và họ phải quản lý session bằng CSDL (ví dụ lưu bảng session…) hay bằng các tập tin tạm thời (ví dụ /tmp/session/) thì họ sẽ viết các chương trình hỗ trợ việc xóa các session này (cron job,scheduler…)
Lựa chọn việc sử dụng GET VÀ POST
- Phương thức GET dc dùng để truy vấn dữ liệu, đối với các thao tác tạo ra sự thay đổi hệ thống thì các phương thức khác như POST hay PUT sẽ dc sử dụng (theo khuyến cáo của W3C tổ chức tạo ra chuẩn http)
Sử dụng captcha, các thông báo xác nhận
- Captcha được sử dụng để nhận biết đối tượng đang thao tác với hệ thống là con người hay không? Các thao tác quan trọng như “đăng nhập” hay là “chuyển khoản” ,”thanh toán” thường là hay sử dụng captcha. Tuy nhiên, việc sử dụng captcha có thể gây khó khăn cho một vài đối tượng người dùng và làm họ khó chịu.
- Các thông báo xác nhận cũng thường dc sử dụng, ví dụ như việc hiển thị một thông báo xác nhận “bạn có muốn xóa hay k” cũng làm hạn chế các kĩ thuật
Cả hai cách trên vẫn có thể bị vượt qua nếu kẻ tấn công có một kịch bản hoàn hảo và kết hợp với lỗi XSS.
Sử dụng token
- Tạo ra một token tương ứng với mỗi form, token này sẽ là duy nhất đối với mỗi form và thường thì hàm tạo ra token này sẽ nhận đối số là”SESSION” hoặc được lưu thông tin trong SESSION. Khi nhận lệnh HTTP POST về, hệ thống sẽ thực hiên so khớp giá trị token này để quyết định có thực hiện hay không.
Một số framework hiện nay như là: aspnet webform,ruby on rails,django, Yii… đã hộ trợ tự động cơ chế token này.
Trong tuần tới, tôi sẽ có 1 bài viết cụ thể hướng dẫn chi tiết về vấn đề tạo token để bảo vệ form trong các ngôn ngữ.
Tuy nhiên việc bảo vệ bằng token này vẫn có thể vượt qua nếu kết hợp với một lỗi XSS
Sử dụng cookie riêng biệt cho trang quản trị
- Một cookie k thể dùng chung cho các domain khác nhau,chính vì vậy việc sử dụng “admin.site.com” thay vì sử dụng “site.com/admin” là an toàn hơn.
Kiểm tra REFERRER
- Kiểm tra xem các câu lệnh http gửi đến hệ thống xuất phát từ đâu. Một ứng dụng web có thể hạn chế chỉ thực hiện các lệnh http gửi đến từ các trang đã dc chứng thực.
Tuy nhiên cách làm này có nhiều hạn chế và không thật sự hiệu quả.
Kiểm tra IP
- Một số hệ thống quan trọng chỉ cho truy cập từ những IP dc thiết lập sẵn
Kĩ thuật CSRF còn có thể được sử dụng với kĩ thuật XSS ( Cross Site Scipting) để tạo ra những cách tấn công tinh vi hơn. Bài tới với chủ đề “XSS & CSRF Những người anh em” sẽ đưa ra các trường hợp CSRF thực hiện thành công khi có sự hỗ trợ từ XSS.