CSRF Protection

1.CSRF là gì?

CSRF( Cross- Site Request Fogery) là cách sử dụng quyền chứng thực của người sử dụng với một website. 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.một trang web của một tên miền khác

Hacker sử dụng kỹ thuật tấn công CSRF để lừa trình duyệt người dùng gửi đi các câu lệnh http đến các ứng dụng web. Trong trường hợp phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ thực hiện với quyền chứng thực của người sử dụng.

2.Kịch bản tấn công

Các ứng dụng Rails sử dụng phiên trên cookie. Trình duyệt gửi phiên kèm theo cookie với mọi yêu cầu đến một tên miền, nếu nó tìm thấy cookie cho tên miền đó. Nếu yêu cầu đến từ một tên miền khác của một trang web nó cũng gửi cùng cookie. Ví dụ:

• Người dùng A truy cập một diễn đàn yêu thích như thường lệ. Một người dùng B khác có ý đồ xấu, đăng tải một thông điệp lên diễn đàn với mục đích xóa đi dự án nào đó mà người dùng A đang làm.

• B sẽ tạo một bài viết, trong đó có chèn thêm.

<img height="0" awidth="0" src="http://www.webapp.com/project/1/destroy" >

Để che giấu đoạn mã trên, với thẻ img có kích thước 0x0 pixel A sẽ không thấy được.

• Nếu A đang truy cập vào tài khoản của mình ở www.webapp.com và chưa thực hiện logout. Trình duyệt của A sẽ đọc các thẻ img và load ảnh từ www.webapp.com, cũng như gửi cùng cookie và sessionID.
• Ứng dụng web ở www.webapp.com sẽ chứng thực A và sẽ xóa project với ID là 1.

Ngoài thẻ img , các thẻ html có thể sử dụng kỹ thuật trên:

<iframe height="0" awidth="0" src="http://www.webapp.com/project/1/destroy"></iframe>

<link ref="stylesheet" href="http://www.webapp.com/project/1/destroy" type="text/css"/>

<background src="http://www.webapp.com/project/1/destroy"/>

<script type="text/javascript" src="http://www.webapp.com/project/1/destroy"/>

3.Cách phòng chống CSRF

3.1. Phía nguời dùng Internet

• 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.

3.2. Các website

• Hạn chế thời gian hiệu lực của session

session[:user_id] = user.id
session[:expires_at] = Time.current + 24.hours

• Lựa chọn việc sử dụng GET VÀ POST

  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 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. Ruby on Rails cũng hỗ trợ cơ chế token.

     class ApplicationController < ActionController::Base
         protect_from_forgery with: :exception
     end

 Khi đó tất cả các form và Ajax request được tự động thêm security token được sinh bởi Rails. Nếu security token không khớp, ngoại lệ sẽ được ném ra.

• 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

Nguồn

http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

http://securitydaily.net/csrf-phan-1-nhung-hieu-ve-biet-chung-ve-csrf

http://securitydaily.net/csrf-phan-2-cach-khac-phuc-va-phong-tranh