Jak zapobiec sytuacji, w której element iframe uzyskuje dostęp do ramki nadrzędnej?

Question

Mam stronę z ramką iframe. Strona i źródło elementu iframe znajdują się w różnych domenach. Wewnątrz elementu iframe używam edytora tekstu sformatowanego o nazwie CuteEditor (który okazał się niezbyt słodki). Istnieją pewne funkcje javascript w CuteEditor, które próbują uzyskać dostęp do "dokumentu", ale przeglądarka odmawia dostępu, ponieważ nie znajdują się w tej samej domenie.

Oto dokładna błędu:

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

Edycja JavaScript jest wykluczone, ponieważ został minfied i ukrywane więc wszystkie nazwy zmiennych są zagadkowe.

Używanie innego edytora jest obecnie wykluczone, ponieważ jest to projekt roboczy i jest to edytor, którego mi polecono.

Czy istnieje sposób na utrzymanie niezależności ramki iframe? Czyli robi wszystko w elemencie iframe i nie próbuje wyłamać się do ramki nadrzędnej?

Answer 1

Nie musisz się martwić, że tak się dzieje.

Jedynym sposobem, w jaki elementy iframe mogą komunikować się z innymi, jest postMessage. Jest to możliwe tylko wtedy, gdy słuchasz bezpośrednio tej domeny.

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

Answer 2

Jeśli iframe dziecko jest ładowany z innej domeny, to nie będzie mógł uzyskać dostępu do strony nadrzędnej lub DOM.

Istnieje jednak nadal możliwa luka w ataku man-in-the-middle w następujący sposób. Załóżmy, że strona wczytuje się http://yoursite.com i iframe idzie http://badsite.org

• pierwszy http://badsite.org przekierowuje do http://yoursite.com/badpage

• Jest to krok, który wymaga atak man-in-the-middle. Osoba atakująca musi albo być w stanie przejść między użytkownikiem a witryną yoursite.com, albo kontrolować odpowiedzi na zapytanie DNS. Jest to łatwiejsze niż się wydaje - każdy, kto ma kontrolę administracyjną nad publicznym punktem dostępu WiFi, może to zrobić (pomyśl o Starbucks, hotelach, lotniskach). Celem jest udostępnienie zawartości witryny http://yoursite.com/badpage ze strony atakującego, a nie Twojej rzeczywistej witryny.

• Osoba atakująca może następnie użyć dowolnego złośliwego kodu z (fałszywego) http://yoursite.org/badpage. Ponieważ znajduje się w tej samej domenie co strona główna, będzie miał dostęp do nadrzędnego DOM.

Atrybut piaskownicy typu HTML5 wydaje się być sposobem uniknięcia tego. Możesz przeczytać spec, ale najlepszym opisem może być here.

Wydaje się być obsługiwany pod Chrome, IE10, FireFox, Safari.

Specyfikacja mówi, że jeśli atrybut "allow-same-origin" ma wartość , a nie, "treść jest traktowana jako pochodząca z unikalnego źródła". Powinno to uniemożliwić dziecku elementowi iframe dostęp do dowolnej części DOM jednostki nadrzędnej, bez względu na to, co przeglądarka uważa za adres URL.