2010-07-26 22 views
5

Tôi có trang https (https://example.com/main.php) có khung nội tuyến có nguồn không phải https (http://example.com/inner.php). Cả hai tệp trên cùng một máy chủ - chỉ một tệp được truy cập bằng https và tệp kia không có. Tôi cần trang phi https để có thể thực thi javascript trên https main.php trang sử dụng mã như parent.myfunction()Cho phép HTTP iFrame gọi JavaScript trên khung cha mẹ HTTPS

Tuy nhiên, khi tôi cố gắng này, tôi nhận được lỗi sau:

Unsafe JavaScript attempt to access frame with URL https://example.com/main.php from frame with url http://example.com/inner.php . Domains, protocols and ports must match.

tôi đã thiết document.domain = 'example.com' trên cả hai tập tin và tôi nghĩ rằng sẽ sửa chữa nó, tuy nhiên, nó không. Có cách nào để cho phép khung thực thi các javascripts trên khung chính và ngược lại không? Nếu vậy, các tác động an ninh của điều này là gì?

PS: Đối với những người trong số các bạn đề xuất chỉ sử dụng https hoặc http cho cả hai trang, tôi đang xem xét điều đó. Tuy nhiên, do các quá trình xảy ra trong trang iframe, điều này có thể không phải là một tùy chọn khả thi do các sự cố tải máy chủ.

Trả lời

5

"Chính sách gốc tương tự" bao gồm giao thức ("http" hoặc "https"), tên máy chủ và số cổng. Tất cả những thứ đó phải khớp hoặc bạn thua.

Nếu tải trên máy chủ của bạn thực sự sẽ bị ảnh hưởng bởi phải áp dụng mã hóa cho trang , thì tôi nghi ngờ bạn có các vấn đề khác, nghiêm trọng hơn nhiều. Trong ngày và tuổi tác đó thực sự không phải là một vấn đề. Nếu bạn có một trang web có lưu lượng truy cập lớn, thì có thể bạn nên sử dụng giao diện người dùng để thực hiện SSL.

0

Bạn không thể thực hiện truy cập tên miền chéo/giao thức chéo/cổng chéo với JavaScript. Điều này được gọi là "tập lệnh miền chéo", đây là vấn đề vì không có bảo mật như thế này, tôi có thể mở Gmail trong khung nội tuyến, nhận hộp văn bản "u" và "p" và có thông tin đăng nhập của người dùng như vậy.

Những gì bạn đưa vào PS là giải pháp thực sự duy nhất mà bạn có thể sử dụng ngoài việc sử dụng máy chủ echo ... sẽ quá mức cần thiết.

4

Nếu đó là bao giờ có thể thực hiện những gì bạn yêu cầu, không có trang web được bảo mật SSL nào sẽ an toàn.

Hãy để tôi mô tả sự cố. Giả sử một người dùng, Alice, truy cập tài khoản của cô ấy trên Paypal.com. Tôi, Mallory, giữa Paypal và Alice. Khi Alice truy cập Paypal, tôi chặn yêu cầu của cô ấy và trả lại một trang chứa hai thứ: một khung với https://paypal.com và một trang chứa một trang có mục đích là 'http://my.paypal.com', mà tôi đã tự tạo ra. Khung HTTPS hợp lệ vì nó thực sự đến từ Paypal. Khung HTTP chứa một số Javascript của thiết bị của tôi sẽ truy cập vào khung HTTPS và khi Alice nhập mật khẩu của mình, nó sẽ gửi cho tôi!

Vì vậy, không, không thể truy cập nội dung an toàn từ nội dung không an toàn, ngay cả trên cùng một tên miền.

+0

Ví dụ của bạn không hoạt động: không thể sử dụng tên miền "my.paypal.com" vì miền _whole_ (với tất cả tên miền phụ hiện có và không tồn tại) thuộc về paypal. Vì vậy, theo ý kiến ​​của tôi, đây không phải là lý do cho giới hạn bảo mật này. Lý do là như nhau, như thể bạn muốn tải bất kỳ nội dung nào thông qua http tại một trang web https. – rudi

+1

@Rudolf Tôi không nghĩ rằng bạn đã hoàn toàn hiểu những gì tôi đã nói. Kẻ tấn công trả về một trang có hai khung * bên trong nó. Một khung có chứa https://paypal.com bona fide. Khác chứa javascript độc hại. JavaScript độc hại "được gửi từ paypal.com" - nhưng thực sự, tôi đã chặn yêu cầu và trả lại bất kỳ nội dung nào tôi muốn (có thể vì nó không phải là kết nối an toàn).Vì vậy, hai khung hình "vượt qua kiểm tra cùng nguồn gốc", nhưng kết quả là thảm họa. – Borealid

Các vấn đề liên quan