Bảo vệ CSRF có cần thiết trên biểu mẫu đăng ký không?

Question

Đường ray tự động thêm bảo vệ CSRF vào tất cả các biểu mẫu theo mặc định bằng cách thêm authentication_token vào tất cả các biểu mẫu được tạo bởi trang web.

Tôi thực sự muốn trang web của mình có biểu mẫu đăng ký đơn giản trên trang đầu của trang web, tất nhiên sẽ là trang HTML tĩnh. Điều này lý tưởng nhất là tránh đụng vào ngăn xếp Rails, cho phép tôi phục vụ nhiều yêu cầu hơn đến trang đầu.

Nhược điểm của việc này là nó giúp bảo vệ CSRF khó khăn hơn. Nhưng tôi tự hỏi liệu có cần thiết phải bảo vệ CSRF trên một mẫu đăng ký hay không, xem xét rằng các cuộc tấn công CSRF thường phụ thuộc vào nạn nhân được đăng nhập để tin tưởng có thể được khai thác. Biểu mẫu đăng ký sẽ đăng nhập người dùng nếu nó xác thực chính xác, nhưng tôi không nghĩ rằng đó sẽ là bất kỳ việc sử dụng nào đối với kẻ tấn công.

Có chế độ xem được thiết lập về điều này hoặc công việc xung quanh sử dụng Rails/jQuery không?

Answer 1

Không, cho trường hợp cụ thể này không. Cuộc tấn công CSRF cho phép kẻ tấn công khai thác các quyền mà nạn nhân có, ví dụ: bank.com/pay?ammount=1000&to=34.67.978.246

Không có ý nghĩa gì khi tấn công biểu mẫu đăng nhập, vì kẻ tấn công có thể tự đăng nhập nếu anh ta có thông tin cần thiết để tấn công thành công vào trường đăng nhập (tên người dùng và mật khẩu).

Lý do tại sao Rails sử dụng bảo vệ CSRF trên các lĩnh vực đăng nhập rất đơn giản: đó là đơn giản hơn nhiều để thực hiện bảo vệ CSRF trên toàn cầu sau đó cho 95% diện tích ruộng;)

Answer 2

Trên CSRF

Trước tiên, người ta phải nêu rõ CSRF là gì.

Cross site request forgery là một loại khai thác độc hại của trang web theo đó các lệnh trái phép được truyền từ người dùng mà trang web tin tưởng.

Hãy xem ví dụ sau: Tin tặc biết rằng bạn có tài khoản trên www.example.com và giả sử đó là trang web bạn đã đăng nhập và vẫn chạy phiên hợp lệ. Giờ đây, tin tặc có thể lôi kéo bạn mở một trang web khác, nói rằng trustme.com, mà trên đó anh ấy đã đăng một hình ảnh có mã sau:

<img src="http://www.example.com/users/delete"/> 

Nếu lập trình viên của www.example.com thực sự có thể xóa tài khoản của bạn thông qua URL đó với yêu cầu GET đơn giản và tin tặc biết rằng, chỉ cần xem và tải hình ảnh đó bằng cookie hợp lệ của bạn sẽ xóa tài khoản của bạn trên example.com, mặc dù bạn chỉ lướt trustme.com và có vẻ như cả hai các trang web không liên quan gì đến nhau.

Để tóm tắt ví dụ này, CSRF khai thác sự tin tưởng rằng trang web có trong trình duyệt của người dùng, trong trường hợp này sự tin tưởng mà www.example.com có ​​trong trình duyệt của bạn.

Để sử dụng tính tương tự cho trường hợp của bạn có nghĩa là khai thác sự tin tưởng của trang web trong trình duyệt của người dùng - nhưng niềm tin đó chưa được thiết lập, bởi vì người dùng chưa đăng nhập khi thấy biểu mẫu của bạn. Bạn phải đảm bảo rằng người dùng được chuyển hướng khi đã đăng nhập và cố gắng tải lại trang với biểu mẫu đó, bởi vì nếu không thì có thể khai thác được sự tin tưởng. Vì vậy, theo quy tắc chung, bất cứ khi nào bạn sử dụng cookie và phiên để yêu cầu xác thực người dùng, tức là để xác nhận hoặc thiết lập niềm tin vào người dùng, hãy sử dụng tính năng bảo vệ CSRF. Vì bạn muốn thiết lập niềm tin vào người dùng của mình khi đăng ký, điều tương tự cũng áp dụng.

Thật không may, các cuộc tấn công CSRF không chỉ giới hạn ở đó. Tôi phát hiện ra hai điều khác có thể xảy ra (và chắc chắn không giới hạn ở đó):

1.: Sau đây là một ví dụ tiện lợi của gián điệp trên tài khoản của bạn, có thể thực hiện bằng cách bỏ qua bảo vệ CSRF về hình thức đăng nhập:

1. Các hacker tạo một tài khoản trên một trang web bạn thực sự tin tưởng (youtrustthis.com)
2. Ông rèn yêu cầu đăng nhập từ trình duyệt của bạn bằng thông tin đăng nhập của chính bạn và sử dụng tài khoản của mình
3. Nếu bạn không nhận thấy rằng bạn đang thực sự truy cập youtrustthis.com với tư cách là một người dùng khác, sau đó kẻ tấn công sẽ xem bạn đã làm gì ", điều này sẽ làm gián điệp bạn nhiều hơn

2: Nếu không có bảo vệ CSRF, hacker có thể bắt chước đăng nhập của bạn hoặc đăng ký biểu mẫu trong tài liệu html của riêng mình và thuận tiện gửi nó một lần nữa (hoặc chỉ cần thực hiện bằng cách sử dụng curl từ thiết bị đầu cuối) mà không nhận thấy rằng yêu cầu không thực sự đến từ chính nó - tức là, biểu mẫu đăng nhập thực tế trên miền đáng tin cậy không bao giờ được hiển thị trong trình duyệt của bạn và không được gửi từ đó. Điều này cho phép anh ta thực hiện các cuộc tấn công brute force dễ dàng hơn nhiều. Nếu người dùng độc hại thành công trong việc cố gắng tìm ra thông tin đăng nhập, máy chủ của bạn sẽ phản hồi bằng cookie phiên hợp lệ và tin tưởng người dùng đó, theo đó anh ta lấy cắp danh tính của bạn. Nếu nó là một hình thức đăng ký, anh ta sẽ có thể đăng ký một lượng lớn tài khoản và do đó spam cơ sở dữ liệu của bạn.

Để tóm tắt điều này: Đi với bảo vệ CSRF. Người dùng độc hại có thể sử dụng rất nhiều thông tin đăng nhập không an toàn và đăng ký biểu mẫu để lạm dụng trang web của bạn và theo dõi người dùng của bạn hoặc lấy cắp danh tính của họ.

Để biết thêm thông tin, hãy tham khảo this similar question (for login forms) và this academic paper. Sau này có một chương dành riêng về CSRF đăng nhập trên trang 3. Ngoài ra, hãy xem CSRF prevention cheat sheet này.

On cách giải quyết tiềm năng

Kể từ bảo vệ CSRF sử dụng phiên để so sánh dấu hiệu tạo ra trên server-side với một trong đó đã được gửi từ một hình thức, tôi không thể nghĩ ra một cách để làm điều duy nhất phía khách hàng này, tức là mà không cần nhấn Rails stack. Toàn bộ vấn đề là khách hàng chỉ nhận được mã thông báo sau khi nó được tạo phía máy chủ.

Answer 3

Nếu bạn muốn cache trang đầu nhưng vẫn có bảo vệ CSRF (có thể là một ý tưởng hay), bạn có thể chèn mã thông báo xác thực phù hợp qua Javascript khi trang đã tải.

Có một số thông tin về điều này tại http://broadcastingadam.com/2011/05/advanced_caching_in_rails/ trong tiêu đề "CSRF và form_authenticty_token". Mã có liên quan là:

$("meta[name='csrf-token']").attr('content', '<% Rack::Utils.escape_html(request_forgery_protection_token) %>'); 
$("meta[name='csrf-param']").attr('content', '<% Rack::Utils.escape_html(form_authenticity_token) %>'); 

Với kỹ thuật này, bạn có thể yêu cầu thêm mã thông báo xác thực (nhưng rất nhỏ và nhanh chóng).

Answer 4

Dường như với tôi rằng có rất ít lý do kỹ thuật để được quan tâm về csrf từ một hình thức đăng ký. Kẻ tấn công có thể lừa ai đó tạo tài khoản mới trên trang web của bạn - nếu nạn nhân sau đó sử dụng trang web của bạn, kẻ tấn công có thể theo dõi hành động của họ vì anh ta cũng có quyền truy cập vào tài khoản?

Rủi ro nhiều khả năng có thể không mang tính kỹ thuật. Khi trang web của bạn nhận được kiểm tra bảo mật, bạn sẽ phải giải thích tại sao csrf không phải là rủi ro ở đây ... và chứng minh một tiêu cực là khó khăn ... "Appscan đã gắn cờ đây là lỗ hổng bảo mật quan trọng - tại sao không bạn sửa chữa nó? Tại sao bạn không thể có một báo cáo sạch đẹp như Charles? " :)

Answer 5

Nói một cách rõ ràng là một ý tưởng tốt để bảo vệ các biểu mẫu đăng ký của bạn khỏi các cuộc tấn công CSRF. Hãy xem xét Tìm kiếm của Google và giả sử biểu mẫu đăng nhập được bảo vệ chống lại CSRF nhưng biểu mẫu đăng ký là dễ bị tổn thương. Kẻ tấn công có thể buộc nạn nhân đăng ký một tài khoản mới với các thông tin mà kẻ tấn công biết, và từ thời điểm đó trên bất kỳ tìm kiếm nào nạn nhân cũng sẽ hiển thị với kẻ tấn công, bởi vì anh ta biết thông tin đăng nhập vào tài khoản nạn nhân. Điều này giả định trang web dễ bị tấn công ngay lập tức đăng nhập vào người dùng sau khi đăng ký.

Kịch bản khác, với nhà cung cấp dịch vụ email, là tạo tài khoản cho mục đích spam. Kẻ tấn công có thể buộc nạn nhân tạo tài khoản mới, với CSRF trong biểu mẫu đăng ký và sử dụng các tài khoản đó để gửi spam. Ý tưởng là để đánh bại các cơ chế bảo mật điều tiết việc tạo tài khoản dựa trên IP hoặc quốc gia.

Tuy nhiên, trong một trường hợp cụ thể, có thể không khai thác được mẫu đăng ký dễ bị tổn thương, nhưng loại phân tích này có thể khó cho một người không phải là chuyên gia trong chủ đề này. Một ý tưởng tốt để bảo vệ biểu mẫu, nhưng không có nhiều kịch bản mà một cuộc tấn công thành công có thể được tạo ra do đó rủi ro thường thấp.