Atrybut iFrame sandbox blokuje wywołania AJAX

Ajax ma wpływ na Ajax, ponieważ Ajax jest regulowany przez Same zasady pochodzenia Zasady, a kiedy sandbox to skutecznie mówisz przeglądarce, aby traktowała zawartość iframe tak, jakby była z innego pochodzenia. Cytując ten sam Artykuł :

• unikalna obróbka pochodzenia. Cała zawartość jest traktowana pod unikalnym pochodzeniem. Treść nie jest w stanie przejść przez DOM ani odczytać informacji o plikach cookie.

Oznacza to, że nawet zawartość pochodząca z tej samej domeny jest traktowana z zasadą cross-domain, ponieważ każda zawartość IFRAME będzie postrzegana jako unikalne pochodzenie.

Zawartość osadzona jest dozwolona tylko do wyświetlania informacji.Nie można wykonać żadnych innych działań wewnątrz iframe , które mogłyby zagrozić stronie hostingowej lub wykorzystać zaufanie użytkowników.

Innymi słowy, jeśli pominiesz allow-same-origin w atrybucie sandbox, będzie on traktował stronę z piaskownicy jako należy do innej domeny (w rzeczywistości będzie traktowana jako posiadająca null pochodzenie). Ponieważ nie ma sensu wysyłanie żądań Ajax do null, strony z piaskownicą nie mogą w ogóle wykonywać wywołań Ajax (jeśli zezwala się na wykonywanie ich do localhost, byłyby one nieodróżnialne od wywołań ze strony nadrzędnej, co nie pozwala na piaskownicę).

Dodatkowe informacje

<script src="http://code.jquery.com/jquery.min.js"></script>
<script>
    console.log(location.host);
    $.post('https://google.com/',{},function() { });
</script>

Jednakże, Jak to się nie powiedzie zależy od użytego atrybutu piaskownicy. Jeśli umieścisz powyższą stronę w iframe z allow-same-origin, wydrukuje to na konsoli:

localhost
XMLHttpRequest cannot load https://google.com/. Origin http://localhost is not allowed by Access-Control-Allow-Origin.

...i jeśli umieścisz go bez allow-same-origin:

localhost
XMLHttpRequest cannot load https://google.com/. Cannot make any requests from null.

Zauważ, że podczas gdy oba zgłaszały location.host jako localhost, jeden uważał pochodzenie za http://localhost, a drugi za null (pokazując ten sam komunikat o błędzie, którego doświadczyłeś w swoim przykładzie).

Rozumowanie

Dlaczego tak jest ważne, aby blokować połączenia Ajax z zawartości piaskownicy z tej samej domeny? Jak wyjaśniono w artykule:

To ma sens, że treści na tej samej domenie powinny być bezpieczne. Ryzyko w tym przypadku wynika przede wszystkim z Treści Generowanych przez użytkowników, które są ponownie hostowane w IFRAME .

Zróbmy przykład: załóżmy, że Facebook zdecyduje się zezwolić użytkownikom na umieszczanie małych animacji HTML5 na swoich stronach. Przechowuje je we własnych serwerach, a gdy wyświetlanie, sandboxy są tylko allow-scripts (ponieważ skrypty są potrzebne do działania animacji), ale pozostawia Wszystko inne zabronione (w szczególności allow-same-origin, ponieważ nie chcesz, aby kod użytkownika mieszał się ze stroną nadrzędną). Co by się stało, gdyby połączenia Ajax nie były domyślnie blokowane?

1. Wykonanie połączenia Ajax do Facebook, przy użyciu jego API (powiedzmy, Open Graph ); serwer z radością przyjmie połączenie, ponieważ z tego, co wie, Prośba pochodziła ze strony z https://facebook.com jako origin.

2. Utwórz URI wskazujące na jej własny serwer, ze zwracanymi danymi jako ciągami zapytań i ustaw go jako src obrazu na stronie piaskownicy.

1. Połączenie Ajax działa w przeglądarce Alice, podczas gdy Alice jest zalogowana; ponieważ serwer nie wie, skąd połączenie pochodzi (Strona główna lub osadzona strona) zrobi wszystko, o co poprosi - w tym pobranie danych osobowych.

2. Gdy element img zostanie utworzony z URI Mallory, przeglądarka spróbuje normalnie załadować "obraz", ponieważ obrazy są wyłączone z tej samej polityki pochodzenia.

3. Ponieważ URI ma prywatne informacje Alice w łańcuchu zapytań, serwer Mallory może po prostu zapisać je i zwrócić dowolny obraz. Teraz Mallory ma dane osobowe Alice, a Alice nic nie podejrzewa.