Bảo vệ CSRF với tiêu đề CORS Origin so với mã thông báo CSRF

103

Câu hỏi này chỉ là về việc bảo vệ chống lại các cuộc tấn công Cross Site Request Forgery.

Đặc biệt là về: Bảo vệ thông qua tiêu đề Nguồn gốc (CORS) có tốt như bảo vệ thông qua mã thông báo CSRF không?

Thí dụ:

Alice đã đăng nhập (sử dụng cookie) bằng trình duyệt của mình vào " https://example.com ". Tôi giả định rằng cô ấy sử dụng một trình duyệt hiện đại.
Alice truy cập " 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 đối với " 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 đề Nguồn 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 an toàn (nhưng nó hơi tẻ nhạt).
Nếu chúng tôi kiểm tra tiêu đề Nguồn gốc, yêu cầu từ mã phía máy khách của evil.com cũng sẽ bị chặn giố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 đề Nguồn gốc.

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

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

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

ứng dụng gốc,
trình duyệt bị thao túng,
lỗi kịch bản trang chéo trong trang example.com,
...

— Chris Lercher
nguồn

Tôi tin rằng nhiều proxy loại bỏ tiêu đề gốc.

— thefourtheye

Và đối với thẻ gửi biểu mẫu 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 khởi tạo qua TLS nên người dùng có một vấn đề cấp bách hơn nhiều so với CSRF nếu một proxy có thể thay thế anh ta / cô ta.

— Perseids

@thefourtheye, tại sao họ lại lột đồ Origin? Điều đó sẽ phủ nhận bảo vệ CORS.

— Paul Draper

Tôi thích câu hỏi này và các câu trả lời của nó vì chúng nói về một cái gì đó cụ thể, nhưng chúng cũng nhắc nhở tôi về sự khác biệt giữa CSRF và CORS. (Tôi thừa nhận đó không phải là những khái niệm dễ nhầm lẫn ... Nhưng tôi vẫn cố gắng nhầm lẫn chúng.)

— The Red Pea

Câu trả lời:

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

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

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

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

Các Origintiêu đề thường chỉ gửi cho XHR yêu cầu cross-domain. 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 bị thao túng,

lỗi kịch bản trang chéo trong trang example.com,

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

— SilverlightFox
nguồn

Ví dụ về Flash là một ví dụ tốt - và có thể các plugin khác có thể có lỗ hổng tương tự. Tôi (rất tiếc) chỉ có thể bảo vệ Alice khỏi CSRF, nếu cô ấy sử dụng trình duyệt hiện đại, v.v., điều đó rõ ràng. Nhưng không phải là không có lý, ngay cả khi là một người dùng hiểu biết về 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 chúng đế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 bị thuyết phục 100%, nếu họ cũng nghĩ về CSRF! Vì vậy, trừ khi hộp cát của trình duyệt hạn chế các plugin vi phạm SOP (có thể không?), Tôi khuyên bạn nên gắn bó với mã thông báo CSRF.

— Chris Lercher,

@ChrisLercher: Có các plugin ngày nay dường như mạnh mẽ 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 để 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ẽ phụ thuộc vào độ nhạy của dữ liệu của bạn và liệu rủi ro như vậy có thể chấp nhận được hay không. Flash tuân theo SOP, nhưng nguồn gốc của plugin Flash là trang web mà nó được tải từ đó (chứ không phải trang web gọi như JavaScript). Có một crossdomain.xmlcó thể cho phép giao tiếp giữa các miền.

— SilverlightFox

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

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

Mối quan tâm chính khi 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à đã đặt 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 theo các quy tắc này, nhưng còn các plugin thì sao? Họ có thể không, nhưng câu hỏi bỏ qua "trình duyệt bị thao túng". Còn các lỗi trong trình duyệt cho phép kẻ tấn công giả mạo tiêu đề Nguồn gốc thì sao? Có thể có lỗi cho phép mã thông báo CSRF bị rò rỉ trên các nguồn gốc, vì vậy sẽ mất nhiều công sức hơn để lập luận rằng cái nào tốt hơn cái kia.

— khách mời
nguồn

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 biểu mẫu 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 tiêu đề gốc sẽ có hiệu quả nếu người dùng đang sử dụng Firefox.

— Andy

Để tham khảo, vấn đề Firefox không gửi tiêu đề "Nguồn gốc" đượ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 đề "Người giới thiệu" trong trường hợp này nhưng theo kinh nghiệm của tôi thì Người dùng Firefox chặn tiêu đề "Người giới thiệu" vì lo ngại về quyền riêng tư (mặc dù IMHO cũng đủ để loại bỏ đường dẫn và truy vấn).

— Steffen