2010-03-28 7 views
23

Tôi đã đọc khoảng CORS và tôi nghĩ việc triển khai vừa đơn giản vừa hiệu quả.Chia sẻ tài nguyên gốc (CORS) - Tôi có thiếu gì đó ở đây không?

Tuy nhiên, trừ khi tôi bỏ lỡ điều gì đó, tôi nghĩ có một phần lớn bị thiếu trong thông số kỹ thuật. Theo tôi hiểu, đó là trang web nước ngoài quyết định, dựa trên nguồn gốc của yêu cầu (và tùy chọn bao gồm thông tin đăng nhập), cho phép truy cập vào tài nguyên của nó hay không. Điều này là tốt.

Nhưng điều gì sẽ xảy ra nếu mã độc trên trang muốn đăng thông tin nhạy cảm của người dùng lên trang web nước ngoài? Các trang web nước ngoài rõ ràng là sẽ xác thực yêu cầu. Do đó, một lần nữa nếu tôi không bỏ lỡ một cái gì đó, CORS thực sự làm cho nó dễ dàng hơn để ăn cắp thông tin nhạy cảm.

Tôi nghĩ rằng nó sẽ có ý nghĩa hơn nhiều nếu trang web gốc cũng có thể cung cấp danh sách bất biến của các máy chủ mà trang của nó được phép truy cập.

Vì vậy, trình tự mở rộng sẽ là:

  1. Cung cấp một trang với danh sách các máy chủ CORS thể chấp nhận được (abc.com, xyz.com, vv)
  2. Trang muốn làm một yêu cầu XHR để abc. com - trình duyệt cho phép điều này vì nó nằm trong danh sách được phép và quá trình xác thực là như bình thường
  3. Trang muốn yêu cầu XHR tới toxic.com - yêu cầu bị từ chối cục bộ (tức là bởi trình duyệt) vì máy chủ không có trong danh sách.

Tôi biết rằng mã độc hại vẫn có thể sử dụng JSONP để thực hiện công việc bẩn thỉu của mình, nhưng tôi đã nghĩ rằng việc triển khai hoàn chỉnh CORS sẽ ngụ ý việc đóng thẻ tập lệnh nhiều trang web.

Tôi cũng đã xem thông số CORS chính thức (http://www.w3.org/TR/cors) và không thể tìm thấy bất kỳ đề cập nào về vấn đề này.

Trả lời

2

Dường như với tôi rằng CORS hoàn toàn mở rộng những gì có thể và cố gắng làm điều đó một cách an toàn. Tôi nghĩ đây rõ ràng là một động thái bảo thủ. Tạo chính sách tên miền chéo nghiêm ngặt hơn trên các thẻ khác (tập lệnh/hình ảnh) trong khi an toàn hơn, sẽ phá vỡ nhiều mã hiện có và khiến việc áp dụng công nghệ mới khó khăn hơn nhiều. Hy vọng rằng, một cái gì đó sẽ được thực hiện để đóng lỗ hổng bảo mật đó, nhưng tôi nghĩ rằng họ cần phải chắc chắn rằng nó là một quá trình chuyển đổi dễ dàng đầu tiên.

+1

Điểm chính của tôi không phải là quá nhiều sự kết thúc của các lỗ hổng hiện tại, đúng hơn là thực tế là có vẻ như (với tôi ít nhất) là một lỗ hổng lớn trong thông số CORS. –

15

Nhưng điều gì sẽ xảy ra nếu mã độc trên trang muốn đăng thông tin nhạy cảm của người dùng lên trang web nước ngoài?

Điều gì về nó? Bạn đã có thể làm điều đó mà không có CORS. Thậm chí trở lại xa như Netscape 2, bạn luôn có thể chuyển thông tin đến bất kỳ trang web của bên thứ ba nào thông qua các yêu cầu GET và POST đơn giản do giao diện đơn giản như form.submit(), new Image hoặc thiết lập window.location.

Nếu mã độc hại có quyền truy cập vào thông tin nhạy cảm, bạn đã hoàn toàn bị mất.

3) Trang muốn làm một yêu cầu XHR để malicious.com - yêu cầu từ chối trong nước

Tại sao một trang sẽ cố gắng để thực hiện một yêu cầu XHR đến một trang web nó chưa trong danh sách trắng?

Nếu bạn đang cố gắng bảo vệ chống lại các hành động của tập lệnh độc hại được tiêm do lỗ hổng XSS, bạn đang cố sửa chữa các triệu chứng, chứ không phải nguyên nhân.

+0

Đồng ý - nhưng chắc chắn nó là mong muốn làm cho nó khó khăn cho một trang bị xâm nhập để ghi thông tin vào một vị trí không thuộc danh sách trắng. Tôi không nhìn thấy nó như là làm việc trên các hiệu ứng hơn là nguyên nhân. Một hầm ngân hàng tốt vẫn sẽ cố gắng làm cho nó rất khó khăn cho những tên cướp để có được tiền ra, ngay cả khi họ đã quản lý để đánh bại an ninh cấp độ đầu tiên và nhận được vào hầm ở nơi đầu tiên. –

+2

Một biện pháp an ninh không hiệu quả là tồi tệ hơn không có biện pháp an ninh. – bobince

+2

"Một hầm ngân hàng tốt sẽ vẫn cố gắng làm cho nó rất khó khăn cho các tên cướp để có được tiền ra, ngay cả khi họ đã quản lý để đánh bại an ninh cấp đầu tiên" Ngay cả kho tiền ngân hàng tốt nhất sẽ không bận tâm để cài đặt, cho ví dụ, một hàng rào thép, biết rằng điều duy nhất mà tên trộm phải làm là đi vòng quanh rào chắn. Như bobince đã nói, một khi bạn có một lỗ hổng XSS, bạn đã hoàn toàn bị mất. – greim

0

Tôi chia sẻ mối quan tâm của David. Bảo mật phải được xây dựng từng lớp và một danh sách trắng được cung cấp bởi máy chủ gốc dường như là một cách tiếp cận tốt.

Ngoài ra, danh sách trắng này có thể được sử dụng để đóng các sơ hở hiện có (biểu mẫu, thẻ tập lệnh, v.v.), an toàn cho rằng máy chủ phục vụ danh sách trắng được thiết kế để tránh các vấn đề tương thích.

+3

Thật không may là lỗ hổng CSRF được đưa vào kiến ​​trúc cơ bản của web. Giờ thì không có gì thay đổi. Ngay cả khi nó * có thể * được thay đổi, nó không rõ ràng rằng nó * nên * được thay đổi. Có những mối quan tâm về an ninh, nhưng an ninh không phải là sự cân nhắc duy nhất trong kế hoạch lớn của sự vật. – greim

3

Nỗi lo của bạn hoàn toàn hợp lệ.

Tuy nhiên, đáng lo ngại hơn là thực tế là không cần phải có bất kỳ mã độc nào hiện diện để điều này được lợi dụng. Có một số lỗ hổng trên trang web dựa trên DOM cho phép kẻ tấn công tận dụng lợi thế của vấn đề bạn đã mô tả và chèn JavaScript độc hại vào các trang web dễ bị tấn công. Vấn đề không chỉ là nơi mà dữ liệu có thể được gửi đi, mà ở đó dữ liệu có thể được nhận từ đó.

tôi nói chuyện về vấn đề này một cách chi tiết hơn ở đây:

0

Tôi cũng kiểm tra ra chính thức CORS spec và không thể tìm thấy bất kỳ đề cập đến vấn đề này.

Phải. Đặc điểm kỹ thuật của CORS đang giải quyết một vấn đề hoàn toàn khác. Bạn nhầm rằng nó làm cho vấn đề tồi tệ hơn - nó làm cho vấn đề không tốt hơn cũng không tồi tệ hơn, bởi vì một khi một tập lệnh độc hại đang chạy trên trang của bạn, nó có thể đã gửi dữ liệu ở bất cứ đâu.

Tin tốt là mặc dù có thông số widely-implemented giải quyết vấn đề này: Content-Security-Policy. Nó cho phép bạn hướng dẫn trình duyệt đặt giới hạn về những gì trang của bạn có thể làm.

Ví dụ: bạn có thể yêu cầu trình duyệt không thực thi bất kỳ tập lệnh nội tuyến nào, điều này sẽ ngay lập tức đánh bại nhiều cuộc tấn công XSS. Hoặc — như bạn đã yêu cầu ở đây — bạn có thể cho trình duyệt biết tên miền nào được cho phép liên lạc.

1

Vấn đề không phải là trang web có thể truy cập vào một tài nguyên trang web khác mà tài khoản đã có quyền truy cập. Vấn đề là một trong những miền - Nếu tôi đang sử dụng một trình duyệt tại công ty của tôi, và một kịch bản ajax độc hại quyết định thử 10.0.0.1 (có khả năng cổng của tôi), nó có thể có quyền truy cập đơn giản chỉ vì yêu cầu hiện đến từ máy tính (có lẽ là 10.0.0.2).

Vì vậy, giải pháp - CORS. Tôi không nói nó là tốt nhất, nhưng là giải quyết vấn đề này.

1) Nếu cổng không thể trả lại tiêu đề gốc được chấp nhận 'bobthehacker.com', yêu cầu bị từ chối bởi trình duyệt. Điều này xử lý các máy chủ cũ hoặc không chuẩn bị.

2) Nếu cổng chỉ cho phép các mục từ miền myinternaldomain.com, nó sẽ từ chối một ORIGIN của 'bobthehacker.com'. Trong trường hợp SIMPLE CORS, nó sẽ thực sự vẫn trả về kết quả. Theo mặc định; bạn có thể cấu hình máy chủ để thậm chí không làm điều đó.Sau đó, kết quả sẽ bị hủy mà không được tải bởi trình duyệt.

3) Cuối cùng, ngay cả khi nó chấp nhận một số miền nhất định, bạn có quyền kiểm soát các tiêu đề được chấp nhận và từ chối để yêu cầu từ các trang đó tuân theo một hình dạng nhất định.

Lưu ý - tiêu đề ORIGIN và OPTIONS được kiểm soát bởi người yêu cầu - rõ ràng là ai đó tạo yêu cầu HTTP của riêng họ có thể đặt bất kỳ thứ gì họ muốn vào đó. Tuy nhiên một trình duyệt tương thích CORS hiện đại WONT làm điều đó. Đây là Trình duyệt kiểm soát tương tác. Trình duyệt đang ngăn bobthehacker.com truy cập vào cổng. Đó là phần bạn đang thiếu.