CSRF ( Cross Site Request Forgery) là kĩ thuật tấn công bằng cách sử dụng quyền chứng thực của người sử dụng đối với 1 website khác. Các ứng dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ người sử dụng, sau đó thực thi các câu lệnh này.
2. Một số điểm DEV thường mắc phải lỗi bảo mật CSRF Khi sử dụng framwork
Các framework hiện nay đã tích hợp và xử lý lỗi bảo mật này, Những một số DEV chưa có kinh nghiệm về lỗ hổng bảo mật này thường thường sau khi research trên google sẽ tắt đi bởi vì khi gọi ajax post không truyền token csrf sẽ báo lỗi.
Tạo 1 form mới nhưng không khai báo token csrf.
3. Nguyên tắc hoạt động của CSRF
Nguyên tắc hoạt động của CRSF rất đơn giản. Chúng ta biết rằng server sẽ lưu trữ cookie ở phía người dùng để phân biệt người dùng. Mỗi khi người dùng gửi một request tới một domain nào đó, cookie sẽ được gửi kèm theo.
Đầu tiên, người dùng phải đăng nhập vào trang mình cần (Tạm gọi là trang A).
Để dụ dỗ người dùng, hacker sẽ tạo ra một trang web độc.
Khi người dùng truy cập vào web độc này, một request sẽ được gửi đến trang A mà hacker muốn tấn công (thông qua form, img, …).
Do trong request này có đính kèm cookie của người dùng, trang web A đích sẽ nhầm rằng đây là request do người dùng thực hiện.
Hacker có thể mạo danh người dùng để làm các hành động như đổi mật khẩu, chuyển tiền, ….
4. Các kiểu tấn công thường gặp
4.1. Kiểu 1. Dùng form
Với 1 phương pháp đơn gianr là : 1 trang web có form đổi mật khẩu có 2 field là password và password_confirm , và 1 button Submit. Hacker sẽ tạo ra 1 web giả với 1 form ẩn với các gía trị tương tự form trên và gửi cho user. Khi user vào link và bấm button submit, thì 1 request đổi password được gửi đến trang web đó, kèm thoe cookie của account user. Cuối cùng hacker chỉ cần dùng email và mật khẩu mới để đăng nhập vào acc của user.
4.2. Kiểu 2. Dùng thẻ img
Ví dụ khi user A muốn chuyển 1 khoản tiền là 1000 cho user B, thì trang web ngân hàng sẽ tạo ra 1 URL, ví dụ URL đó như sau: http://jav.bank?from=Person1&to=Person2&amount=1000. Hacker sẽ bỏ URL này vào 1 thẻ img. Khi user truy cập vào trang, trình duyệt sẽ tự gọi GET request, gắn kèm với cookie của user. Thông qua cookie, ngân hàng xác nhận đó là user, rồi chuyển tiền cho Hacker.
5. Cách phòng chống tấn công CSRF
5.1. Phía user
Để 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
5.2. Phía server
Cấu hình Web.config đơn giản giúp website an toàn
Lựa chọn việc sử dụng GET VÀ POST. Sử dụng GET và POST đúng cách. Dùng GET nếu thao tác là truy vấn dữ liệu. Dùng POST nếu các thao tác tạo ra sự thay đổi hệ thống (theo khuyến cáo của W3C tổ chức tạo ra chuẩn http) Nếu ứng dụng của bạn theo chuẩn RESTful, bạn có thể dùng thêm các HTTP verbs, như PATCH, PUT hay DELETE
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 được 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.
Sử dụng cookie riêng biệt cho trang quản trị: Một cookie không 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 đã được 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 được thiết lập sẵn