Tôi luôn tự hỏi mục đích của các hạn chế miền chéo XHR là gì.Mục đích của các hạn chế miền chéo XHR là gì?
Dường như mục đích là để ngăn JavaScript bị tiêm độc hại gửi dữ liệu cá nhân đến kẻ tấn công. Tuy nhiên, việc gửi dữ liệu đến bất kỳ tên miền nào cũng có thể dễ dàng với một thẻ được chèn script hoặc img (hoặc bất kỳ tài nguyên bên ngoài nào khác cho vấn đề đó).
Nếu bất kỳ trang web tùy ý có thể thực hiện cuộc gọi XHR để trang web của bạn, sau đó những điều sau đây có thể xảy ra:
Chính vì vậy, ngay cả với chính sách tên miền chéo, trang web độc hại của Bob có thể thực sự POST yêu cầu HTTP tới máy chủ của bạn bằng cách đăng biểu mẫu. Nó sẽ không thể nhìn thấy kết quả, nhưng nếu Bob thông minh anh ta có thể đã phát hiện một URL trong trang web của bạn cho phép một số hoạt động từ POST ngay cả khi nó không phải từ một biểu mẫu trên một trong các trang của bạn. Đó được gọi là Giả mạo yêu cầu qua trang web và đó là điều mà trình duyệt không thể bảo vệ bạn.
Bạn có thể tạo trang web để truy cập một số trang web gây ra DoS. Đó là một trong những hiểm hoạ có thể xảy ra khi sử dụng XHR chéo.
Bạn có thể làm tương tự bằng cách bao gồm hàng trăm hình ảnh vô hình từ trang web khác với thông số nhận ngẫu nhiên. – kassens
Kiểm tra bài viết wiki sau đây có thể hữu ích.
Bài viết liệt kê các cách để phá vỡ hạn chế. Những cách giải quyết này là những gì khiến tôi tự hỏi mục đích của biện pháp an ninh duy nhất này. Nó có vẻ như chắn một cửa sổ của một ngôi nhà trong khi cánh cửa và cửa sổ khác mở rộng. – kassens
chính sách bảo mật tương tự tại chỗ được thiết kế để cho một kẻ tấn công để có thể tiêm script độc hại vào một trang web là một trong những điều sau đây là cần thiết:
Nếu bạn xây dựng trang web của mình chỉ tham chiếu tài nguyên trên tên miền của riêng mình và bạn không làm bất kỳ điều gì ngu ngốc như chấp nhận javascript (hoặc SQL) được nhúng trong URL hoặc sử dụng javascript eval() trên văn bản nhập của người dùng, bạn tương đối hình dạng tốt cho bảo mật dữ liệu trên trang web của bạn.
Nếu bạn liên kết đến tài nguyên tập lệnh hoặc hình ảnh nằm trên một miền khác, bảo mật trang web của bạn cũng phụ thuộc vào tính bảo mật của miền bên ngoài đó.
Cách tốt nhất để bảo vệ chống lại # 3 ở trên (người ở giữa cuộc tấn công) là bảo mật mọi yêu cầu tới máy chủ của bạn (đối với trang, tập lệnh và hình ảnh) bằng giao thức https thay vì http.Người đàn ông ở giữa không thể tạo ra một chứng chỉ mã hóa hợp lệ cho miền mục tiêu, vì vậy trình duyệt ít nhất cũng có thể cảnh báo người dùng rằng có điều gì đó đáng sợ về trang web.
Trường hợp cổ điển cho bảo mật cùng một trang web đang bao gồm trang web mục tiêu trong khung nội tuyến trên trang được lưu trữ bởi máy chủ evil.com của kẻ tấn công. Nếu URL trang gốc và URL nội dung iframe nằm trên cùng một tên miền, thì chúng được phép trao đổi với nhau và xem dữ liệu nội bộ, biến, DOM của nhau, v.v. Nếu các tên miền khác nhau, chính sách bảo mật cùng tên miền tuyên bố rằng trình duyệt không được phép iframe xem bất kỳ biến hoặc thông tin DOM nào của cha mẹ hoặc cũng không phải là cấp độ gốc để xem các biến hoặc DOM của nội tuyến khung nội tuyến. Điều này nhằm ngăn chặn việc trao đổi dữ liệu không mong muốn hoặc không thích hợp giữa hai miền.
Nếu chính sách bảo mật miền giống nhau bị thiếu, thì việc tấn công trang web ngân hàng của bạn trong khung nội tuyến là một vấn đề rất đơn giản, dẫn bạn nhầm lẫn (liên kết trên email giả được gửi tới bạn) để đăng nhập thông qua trang web được bao bọc và tình cờ thực hiện tất cả hoạt động ngân hàng của bạn. Từ đó, họ có thể rút tài khoản của bạn chỉ trong vài giây.
Cũng lưu ý rằng XHR đã được thêm vào môi trường trình duyệt dưới dạng tiện ích mở rộng của bên thứ ba ban đầu, do đó, hành động tốt nhất là làm theo mô hình bảo mật trình duyệt hiện tại cho các yêu cầu của khách hàng. XHR tuân theo các quy tắc tương tự như trình duyệt sử dụng để tìm nạp các trang html, tập lệnh và hình ảnh. Nếu XHR được thiết kế thành thông số HTML ngay từ đầu thay vì được giải quyết sau, mọi thứ có thể khác với XHR. Xem ví dụ HTML5 PostMessage spec.
+1 - Tôi có thể có số của Alice không? – jAndy
Nó sẽ không phải là một giải pháp tốt hơn không bao gồm cookie? Điều này sẽ tránh được nhu cầu hack như JSONP. Vấn đề duy nhất tôi có thể thấy là 'bảo mật' dựa trên IP (ví dụ như trong bộ định tuyến gia đình). – kassens
Chặn cookie phiên trên các yêu cầu XHR có nghĩa là trang web có người dùng đã đăng nhập (mã thông báo xác thực được lưu trữ trong cookie phiên) không thể nói chuyện với máy chủ web qua XHR, bởi vì mỗi yêu cầu XHR sẽ thiếu thông tin mã thông báo auth thường bị tấn công vào yêu cầu của trình duyệt dưới dạng cookie phiên. Bạn có thể nhúng thông tin auth trong yêu cầu XHR mà không cần sử dụng cookie, nhưng bạn phải viết mã để nhúng nó vào máy khách và mã để trích xuất nó trên máy chủ. Và bên cạnh đó, cookie chỉ là một khía cạnh của vấn đề truy cập chéo trang. Xem câu trả lời của tôi để biết thêm. – dthorpe