AntiForgeryToken trong ASP.NET MVC có ngăn chặn được tất cả các cuộc tấn công CSRF không?

Question

Sử dụng AntiForgeryToken yêu cầu mỗi yêu cầu chuyển một mã thông báo hợp lệ, vì vậy các trang web độc hại với dữ liệu gửi kịch bản đơn giản tới ứng dụng web của tôi sẽ không thành công.

Nhưng nếu một tập lệnh độc hại trước tiên sẽ thực hiện một số yêu cầu GET đơn giản (để Ajax) để tải xuống trang chứa mã thông báo antiforgery trong trường nhập ẩn, trích xuất và sử dụng nó để tạo POST hợp lệ?

Có thể không hoặc tôi đang thiếu gì đó?

Answer 1

Có, đây là tất cả những gì bạn cần làm.

Chừng nào bạn tạo ra một thẻ mới trên mỗi trang được bảo vệ, với <%= Html.AntiForgeryToken() %> và luôn đảm bảo nó sẽ được kiểm tra trong bất kỳ hành động bảo vệ, sử dụng [ValidateAntiForgeryToken]

này thực hiện các mẫu Synchronizer Mã như đã thảo luận tại CSRF Prevention Cheat Sheet tại OWASP .

Để kịch bản thành công trong việc đưa ra yêu cầu có thể chấp nhận được, trước tiên nó sẽ nhận biểu mẫu và đọc mã thông báo và sau đó đăng mã thông báo. Same Origin Policy sẽ ngăn không cho phép điều này trong trình duyệt. Một site canot thực hiện yêu cầu http kiểu AJAX đến một trang khác; chỉ với chính nó. Nếu vì một lý do nào đó, chính sách gốc có thể bị vi phạm, thì bạn sẽ trở nên dễ bị tổn thương. Lưu ý rằng nếu bạn có lỗ hổng tập lệnh cross-site, kẻ tấn công có thể lạm dụng lỗ hổng xss để tránh sự bảo vệ được cung cấp bởi cùng chính sách gốc (vì tập lệnh hiện đang chạy từ trang web của bạn, do đó SOP thành công) . Sau đó, tập lệnh được tiêm có thể đọc và gửi lại mã thông báo một cách vui vẻ. Kỹ thuật này để vượt qua bảo vệ CSRF thông qua XSS đã được phổ biến trong một số sâu gần đây. Về cơ bản, nếu bạn có XSS, bảo vệ CSRF của bạn là một sự lãng phí thời gian, vì vậy hãy đảm bảo bạn cũng không dễ bị tổn thương.

Một điều cần lưu ý khác là Flash và Silverlight. Cả hai công nghệ này không đăng ký chính sách gốc giống nhau và thay vào đó sử dụng các tệp chính sách tên miền chéo để hạn chế quyền truy cập vào tài nguyên từ xa. Tập lệnh Flash/Silverlight chỉ có thể truy cập tài nguyên trên trang web của bạn nếu bạn xuất bản tệp xml chính sách tên miền chéo trên trang web của riêng mình. Nếu bạn xuất bản tệp này, chỉ bao giờ cho phép danh sách trắng các máy chủ của bên thứ ba đáng tin cậy và không bao giờ cho phép *.

Đọc thêm về CSRF at OWASP Xem thêm: XSS Prevention Cheat Sheet

Answer 2

Nhưng nếu kịch bản độc hại sẽ làm đầu tiên một số yêu cầu GET đơn giản (bằng AJAX) để tải trang chứa antiforgery thẻ trong trường nhập ẩn, chiết xuất nó và sử dụng nó để tạo POST hợp lệ?

Vâng, điều này đúng, nhưng nếu nó không kết thúc trong trình duyệt thì đây KHÔNG phải là cuộc tấn công CSRF.

Nếu nó kết thúc trình duyệt (ví dụ như cạo qua yêu cầu HTTP trong mã phía máy chủ) thì điều gì sẽ xảy ra mã scrape sẽ nhận được mã thông báo CSRF. Tuy nhiên, người dùng hợp pháp, được xác thực của bạn sẽ nhận được một mã thông báo khác được đặt trên máy của họ. Bởi vì mã thông báo rằng các thang máy scraper khác với mã được cấp cho người dùng của bạn thì POST sẽ không thành công.

Nếu bạn muốn dừng các tập lệnh không phải trình duyệt tạo bài đăng thì bạn cần thực hiện một cách tiếp cận khác để xác thực đó là con người.