2011-12-05 36 views
8

Tôi có một trang có khung nội tuyến. Trang và nguồn của khung nội tuyến nằm trong các miền khác nhau. Bên trong khung nội tuyến tôi đang sử dụng một trình soạn thảo văn bản có tên gọi là CuteEditor (đã trở nên không dễ thương). Có một số hàm javascript nhất định trong CuteEditor cố gắng truy cập 'tài liệu' nhưng trình duyệt từ chối truy cập vì chúng không nằm trong cùng một miền.Làm cách nào để ngăn chặn khung nội tuyến truy cập vào khung chính?

Dưới đây là những lỗi chính xác:

Permission denied to access property 'document' http://dd.byu.edu/plugins/cuteeditor_files/Scripts/Dialog/DialogHead.js Line 1

Việc chỉnh sửa javascript là ra câu hỏi vì nó được minfied làm cho khó hiểu vì vậy tất cả các tên biến là khó hiểu.

Sử dụng trình chỉnh sửa khác hiện không nằm trong câu hỏi vì đây là dự án công việc và đây là trình chỉnh sửa mà tôi được yêu cầu sử dụng.

Có cách nào để giữ khung nội tuyến độc lập không? Vì vậy, nó làm mọi thứ bên trong khung nội tuyến và không cố gắng thoát ra khỏi khung chính?

Trả lời

-2

Bạn không cần phải lo lắng về điều đó đang xảy ra.

Cách duy nhất mà iframe có thể nói bắt nguồn chéo là với postMessage và điều đó chỉ có thể xảy ra nếu bạn đang nghe trực tiếp tên miền đó.

https://developer.mozilla.org/en/DOM/window.postMessage

+0

Tuy nhiên, CuteEditor không hoạt động bên trong iframe vì lỗi này. Có vấn đề gì khác không? – Justin

+0

Tôi không chắc chắn. Chúng tôi cần xem mã nguồn của bạn. –

7

Nếu iframe con được nạp từ một tên miền khác nhau, sau đó nó sẽ không thể truy cập vào trang mẹ hoặc DOM.

Tuy nhiên, vẫn có một lỗ hổng có thể xảy ra đối với cuộc tấn công cấp trung gian như sau. Giả sử tải trang của bạn tắt http://yoursite.com và iframe đi vào http://badsite.org

  • đầu tiên http://badsite.org chuyển hướng đến http://yoursite.com/badpage

  • Đây là bước đòi hỏi một cuộc tấn công man-in-the-middle. Kẻ tấn công phải có thể nhận được giữa người dùng và yoursite.com hoặc kiểm soát các câu trả lời cho tra cứu DNS của bạn. Điều này dễ hơn âm thanh - bất kỳ ai có quyền kiểm soát hành chính đối với điểm truy cập WiFi công cộng đều có thể làm điều đó (nghĩ Starbucks, khách sạn, sân bay.) Mục tiêu là phục vụ nội dung của http://yoursite.com/badpage từ trang web của kẻ tấn công chứ không phải trang web thực của bạn.

  • Kẻ tấn công sau đó có thể phục vụ bất kỳ mã độc hại nào họ thích từ (giả) http://yoursite.org/badpage. Bởi vì đây là trong cùng một tên miền như trang chính, nó sẽ có quyền truy cập vào DOM mẹ.

Thuộc tính hộp cát iframe HTML5 có vẻ là cách để tránh điều này. Bạn có thể đọc số spec, nhưng mô tả tốt nhất có thể là here.

Điều này dường như được hỗ trợ trên Chrome, IE10, FireFox, Safari.

Thông số nói rằng nếu thuộc tính "cho phép cùng một nguồn gốc" là không đặt ", nội dung được coi là từ một nguồn gốc duy nhất". Điều này sẽ ngăn chặn iframe con của bạn truy cập vào bất kỳ phần nào của DOM của cha mẹ, bất kể trình duyệt nghĩ URL là gì.

+0

Cuộc tấn công không dễ dàng như đã nêu. Khi thiết bị nhận địa chỉ đến yoursite.com từ DNS, thiết bị sẽ lưu vào bộ nhớ cache để truy cập thêm. Để triển khai hoàn toàn tấn công này, cần có proxy HTTP và người dùng ở giữa sẽ phải viết lại trang web để sử dụng http://yoursite.com/badpage dưới dạng iframe src. Điều này phức tạp hơn nếu bạn sử dụng HTTPS, vì proxy sẽ phải bắt chước HTTPS dưới dạng HTTP để thay đổi các trang. Nó không phải là không thể, nhưng trừ khi trang web là hấp dẫn đối với kẻ tấn công (như ngân hàng, đấu giá hoặc các trang web truy cập cực kỳ có thể được sử dụng để thu hoạch mật khẩu), tiếp xúc của bạn là thấp. – fernacolo

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