Câu hỏi Bảo vệ CSRF với tiêu đề gốc CORS so với mã thông báo CSRF


Câu hỏi này là về bảo vệ chống lại Cross Site Request Forgery attacks.

Cụ thể là: Bảo vệ thông qua tiêu đề Gốc (CORS) có tốt bằng cách bảo vệ thông qua mã thông báo CSRF không?

Thí dụ:

  • Alice được đăng nhập (sử dụng cookie) với trình duyệt của mình để "https://example.comTôi cho rằng, cô ấy sử dụng một trình duyệt hiện đại.
  • Alice thăm "https://evil.com"và mã phía máy khách của evil.com thực hiện một số loại yêu cầu"https://example.com"(kịch bản CSRF cổ điển).

Vì thế:

  • Nếu chúng tôi không kiểm tra tiêu đề Gốc (phía máy chủ) và không có mã thông báo CSRF, chúng tôi có lỗ hổng bảo mật CSRF.
  • Nếu chúng tôi kiểm tra mã thông báo CSRF, chúng tôi sẽ an toàn (nhưng hơi buồn tẻ).
  • Nếu chúng ta kiểm tra tiêu đề Origin, yêu cầu từ mã phía khách hàng của evil.com sẽ bị chặn cũng như khi sử dụng mã thông báo CSRF - ngoại trừ, nếu có thể bằng cách nào đó mã của evil.com đặt tiêu đề Gốc.

Tôi biết, điều này không thể thực hiện được với XHR (xem ví dụ Bảo mật cho chia sẻ tài nguyên gốc), ít nhất là không, nếu chúng ta tin tưởng đặc tả W3C được triển khai đúng trong tất cả các trình duyệt hiện đại (chúng ta có thể?)

Nhưng còn về các loại yêu cầu khác - ví dụ: gửi biểu mẫu? Đang tải thẻ tập lệnh / img / ...? Hoặc bất kỳ cách nào khác một trang có thể sử dụng để (hợp pháp) tạo một yêu cầu? Hoặc có thể một số JS được biết đến hack?

Lưu ý: Tôi không nói về

  • ứng dụng gốc,
  • trình duyệt được điều khiển,
  • lỗi trang web chéo trong trang của example.com,
  • ...

76
2017-07-10 15:17


gốc


Tôi tin rằng nhiều proxy đã loại bỏ tiêu đề gốc. - thefourtheye
Và đối với các biểu mẫu gửi và thẻ img / script, chúng ta nên dựa vào CSP, không chắc chắn về các trình duyệt cũ. - thefourtheye
@thefourtheye: Vì kết nối được bắt đầu trên TLS, người dùng có vấn đề cấp bách hơn CSRF nếu proxy có thể là người trung gian. - Perseids
@thefourtheye, tại sao họ sẽ dải Origin? Điều đó sẽ phủ nhận sự bảo vệ của CORS. - Paul Draper
Tôi thích câu hỏi này và câu trả lời của họ bởi vì họ là về một cái gì đó cụ thể, nhưng họ cũng nhắc nhở tôi về sự khác biệt giữa CSRF và CORS. (Tôi thừa nhận đó là không dễ dàng nhầm lẫn khái niệm ... Nhưng tôi vẫn cố làm họ bối rối.) - The Red Pea


Các câu trả lời:


biết rằng điều này không thể thực hiện được với XHR (xem phần Bảo mật để chia sẻ tài nguyên gốc), ít nhất là không, nếu chúng ta tin tưởng đặc tả W3C được triển khai đúng trong tất cả các trình duyệt hiện đại (chúng ta có thể?)

Vào cuối ngày, bạn phải "tin tưởng" trình duyệt của khách hàng để lưu trữ an toàn dữ liệu của người dùng và bảo vệ phía máy khách của phiên. Nếu bạn không tin tưởng trình duyệt của khách hàng, thì bạn nên ngừng sử dụng trang web cho bất kỳ điều gì khác ngoài nội dung tĩnh. Ngay cả khi sử dụng mã thông báo CSRF, bạn vẫn tin tưởng trình duyệt của khách hàng tuân thủ chính xác Chính sách xuất xứ giống nhau.

Mặc dù đã có các lỗ hổng trình duyệt trước đó như các lỗ hổng trong IE 5.5 / 6.0 nơi những kẻ tấn công có thể bỏ qua Chính sách xuất xứ tương tự và thực hiện các cuộc tấn công, bạn thường có thể mong đợi những bản vá này được vá ngay khi được phát hiện và hầu hết các trình duyệt tự động cập nhật, rủi ro này sẽ giảm thiểu.

Nhưng còn về các loại yêu cầu khác - ví dụ: gửi biểu mẫu? Đang tải thẻ tập lệnh / img / ...? Hoặc bất kỳ cách nào khác một trang có thể sử dụng để (hợp pháp) tạo một yêu cầu? Hoặc có thể một số JS được biết đến hack?

Các Origin tiêu đề thường chỉ được gửi cho các yêu cầu miền chéo XHR. Yêu cầu hình ảnh không chứa tiêu đề.

Lưu ý: Tôi không nói về

  • ứng dụng gốc,

  • trình duyệt được điều khiển,

  • lỗi trang web chéo trong trang của example.com,

Tôi không chắc liệu điều này có nằm trong trình duyệt được điều khiển hay không, nhưng phiên bản cũ của Flash cho phép các tiêu đề tùy ý được đặt để cho phép kẻ tấn công gửi yêu cầu với giả mạo referertiêu đề từ máy của nạn nhân để thực hiện một cuộc tấn công.


31
2017-07-11 07:40



Ví dụ về Flash là một ví dụ hay - và có thể các plugin khác có thể có lỗ hổng tương tự. Tôi có thể (không may) chỉ bảo vệ Alice khỏi CSRF, nếu cô ấy sử dụng một trình duyệt hiện đại, vâng, điều đó rõ ràng. Nhưng nó không phải là không hợp lý, mà ngay cả khi một người dùng nhận thức bảo mật, cô ấy có thể đã cài đặt các plugin của bên thứ 3 - đặc biệt là khi họ đến từ các công ty lớn (đáng tin cậy). Mặc dù họ có thể viết các plugin an toàn, tôi không tin tưởng 100%, nếu họ cũng nghĩ về CSRF! Vì vậy, trừ khi các hộp cát trình duyệt hạn chế các plugin từ vi phạm SOP (chúng có thể?), Tôi muốn khuyên bạn nên gắn thẻ CSRF. - Chris Lercher
@ChrisLercher: Có các plugin hiện đại ngày dường như mạnh hơn một chút. Tuy nhiên, tại bất kỳ thời điểm nào, một phiên bản mới có thể được phát hành, cho phép kẻ tấn công tận dụng nó theo cách như vậy để vượt qua sự bảo vệ của trình duyệt. Cách tốt nhất để xử lý nó (ví dụ: mã thông báo / tiêu đề) sẽ tùy thuộc vào độ nhạy của dữ liệu của bạn và liệu rủi ro đó có được chấp nhận hay không. Flash tuân theo SOP, nhưng nguồn gốc của plugin Flash là trang web được tải từ (thay vì trang web gọi điện như JavaScript). Đây là một crossdomain.xml có thể cho phép liên lạc giữa nhiều miền. - SilverlightFox


Nội dung web không thể giả mạo với tiêu đề Gốc. Hơn nữa, theo cùng chính sách gốc, một nguồn gốc thậm chí không thể gửi tiêu đề tùy chỉnh đến các nguồn gốc khác. [1]

Do đó, việc kiểm tra tiêu đề Gốc cũng tốt chặn các cuộc tấn công khi sử dụng mã thông báo CSRF.

Mối quan tâm chính với việc dựa vào điều này là liệu nó có cho phép tất cả các yêu cầu hợp pháp hoạt động hay không. Người hỏi biết về vấn đề này và đã thiết lập câu hỏi để loại trừ các trường hợp chính (không có trình duyệt cũ, chỉ HTTPS).

Các nhà cung cấp trình duyệt tuân thủ các quy tắc này, nhưng về plugin thì sao? Họ có thể không, nhưng câu hỏi bỏ qua "trình duyệt được điều khiển". Điều gì về lỗi trong trình duyệt cho phép kẻ tấn công giả mạo tiêu đề Gốc? Có thể có lỗi cho phép mã thông báo CSRF bị rò rỉ trên toàn bộ nguồn gốc, do đó, sẽ mất nhiều công sức hơn để tranh luận rằng mã thông báo tốt hơn cái kia.


24
2017-07-11 00:38



Tôi vừa thử nghiệm Firefox 47 và nó không gửi tiêu đề gốc cho một bài đăng hình thức có nguồn gốc chéo (một cách phổ biến để tấn công các dịch vụ REST không kích hoạt CORS cho XHR), vì vậy tôi không nghĩ rằng kiểm tra đầu trang gốc sẽ có hiệu lực nếu người dùng đang sử dụng Firefox. - Andy
Để tham khảo, vấn đề Firefox không gửi tiêu đề "Origin" được theo dõi tại Bugzilla: bugzilla.mozilla.org/show_bug.cgi?id=446344 Bạn có thể dự phòng để kiểm tra tiêu đề "Referer" trong trường hợp này nhưng theo kinh nghiệm của tôi, một số người dùng Firefox chặn header "Referer" vì những lo ngại về quyền riêng tư (mặc dù IMHO sẽ đủ để loại bỏ đường dẫn và truy vấn). - Steffen