Dlaczego elementy iframe są uważane za niebezpieczne i stanowią zagrożenie dla bezpieczeństwa?
125
Dlaczego elementy iframe są uważane za niebezpieczne i stanowią zagrożenie dla bezpieczeństwa? Czy ktoś może opisać przykład przypadku, w którym można go użyć złośliwie?
@Samich - Nie, chodzi o najlepsze praktyki, a nie konkretnie o kwestie bezpieczeństwa (a jedyny problem z bezpieczeństwem, jaki przychodzi mi do głowy, wynika z używania ramek iframe przez strony trzecie )
Quentin
Nie tyle bezpieczeństwo, ile nie jest to uważane za najlepszą praktykę, zobacz: stackoverflow.com/questions/1081315/why-developers-hate-iframes Były o wiele bardziej popularne, gdy ludzie projektują również tabele, dzieląc wszystko, ale eliminując potrzebę iframe.
RandomUs1r
Co zabawne, prawie dziesięć lat później pojawił się artykuł, który sugeruje, że umieszczenie czegokolwiek, co zawiera formularz w ramce iframe, odizolowanej od całego javascript innych firm itp., Jest prawdopodobnie konieczne, aby chronić formularze przed gromadzeniem. hackernoon.com/…
GordonM
Odpowiedzi:
84
Gdy tylko wyświetlasz zawartość z innej domeny, zasadniczo ufasz tej domenie, że nie będzie wysyłać złośliwego oprogramowania.
Nie ma nic złego w elementach iframe jako takich. Jeśli kontrolujesz zawartość iframe, są one całkowicie bezpieczne.
Gdy tylko utworzysz link do treści z innej domeny itp., Itd.… Nie ma w tym nic konkretnego elementu iframe.
Quentin
5
Prawidłowo zaimplementowane przeglądarki (inaczej User Agent) nie pozwolą zawartości iframe na wyciek poza iframe. Jeśli dokument główny (taki, który zawiera <iframe>element) ma odpowiedni styl i podpowiedzi, że ramka iframe zawiera niezaufaną zawartość, nie ma problemu. Oczywiście modulo to prawdziwe luki w przeglądarce. Krótko mówiąc, <iframe>jest tak samo bezpieczny jak plik <a href>.
Mikko Rantalainen
2
A co z ukrytym elementem iframe należącym do tej samej domeny? Czy to jest całkowicie bezpieczne?
Ciaran Gallagher,
2
Ukryte w <iframe>tej samej domenie może spowodować zagrożenie bezpieczeństwa, jeśli zawartość ukrytego elementu iframe może zostać zmodyfikowana przez atakującego. Pozwoli to atakującemu na rozszerzenie ataku XSS wewnątrz ukrytego <iframe>na dowolną stronę w Twojej witrynie, która odnosi się do wspomnianej <iframe>treści. Aby uzyskać szczegółowe informacje, zobacz stackoverflow.com/a/9428051/334451 .
Mikko Rantalainen
Co ciekawe, iFrame może w rzeczywistości być użyteczną ochroną przed odwrotnym przypadkiem. Jeśli masz w witrynie wiele skryptów innych firm, musisz odizolować od nich formularze. Jednym z sugerowanych sposobów było umieszczenie formularza na własnej minimalnej stronie bez javascript innej firmy i wyświetlenie go w ramce iframe na stronie hosta. hackernoon.com/…
GordonM
140
IFRAMEElement może stanowić zagrożenie bezpieczeństwa, jeśli witryna jest osadzony wewnątrz IFRAMEna miejscu nieprzyjaznym . Więcej informacji o „clickjackingu” Google. Zauważ, że nie ma znaczenia, czy jesteś używać <iframe>czy nie. Jedyną prawdziwą ochroną przed tym atakiem jest dodanie nagłówka HTTP X-Frame-Options: DENYi nadzieja, że przeglądarka zna swoje zadanie.
Ponadto element IFRAME może stanowić zagrożenie bezpieczeństwa, jeśli jakakolwiek strona w Twojej witrynie zawiera lukę XSS, którą można wykorzystać . W takim przypadku osoba atakująca może rozszerzyć atak XSS na dowolną stronę w tej samej domenie, którą można przekonać do załadowania <iframe>na stronie z luką XSS. Dzieje się tak, ponieważ treść z tego samego źródła (tej samej domeny) ma dostęp do nadrzędnego DOM zawartości (praktycznie wykonuje JavaScript w dokumencie „host”). Jedyną prawdziwą metodą ochrony przed tym atakiem jest dodanie nagłówka HTTP X-Frame-Options: DENYi / lub zawsze prawidłowe kodowanie wszystkich danych przesłanych przez użytkownika (to znaczy nigdy nie ma luki XSS w witrynie - łatwiej powiedzieć niż zrobić).
To jest techniczna strona problemu. Ponadto pojawia się problem z interfejsem użytkownika. Jeśli nauczysz swoich użytkowników, aby ufali, że pasek adresu URL nie powinien się zmieniać po kliknięciu linków (np. Twoja witryna używa dużego elementu iframe z całą rzeczywistą treścią), to użytkownicy nie zauważą niczego w przyszłości również w przypadku rzeczywistego bezpieczeństwa słaby punkt. Na przykład w witrynie może istnieć luka w zabezpieczeniach XSS, która umożliwia atakującemu ładowanie treści z wrogiego źródła w ramach elementu iframe. Nikt nie był w stanie stwierdzić różnicy, ponieważ pasek adresu URL nadal wygląda identycznie jak poprzednie zachowanie (nigdy się nie zmienia), a treść „wygląda” na prawidłową, mimo że pochodzi z wrogiej domeny żądającej danych logowania użytkownika.
Jeśli ktoś twierdzi, że użycie <iframe>elementu w Twojej witrynie jest niebezpieczne i stwarza zagrożenie bezpieczeństwa, nie rozumie, co to <iframe>robi, lub mówi o możliwości wystąpienia <iframe>powiązanych luk w przeglądarkach. Bezpieczeństwo <iframe src="...">tagu jest równe <img src="..."lub <a href="...">tak długo, jak długo nie ma luk w przeglądarce. A jeśli istnieje odpowiednia luka, to może być możliwe, aby wyzwolić go nawet bez używania <iframe>, <img>lub <a>elementu, więc nie jest to warte rozważenia tego problemu.
Należy jednak pamiętać, że zawartość z <iframe>może domyślnie inicjować nawigację najwyższego poziomu . Oznacza to, że treść w ramach <iframe>może automatycznie otwierać łącze w bieżącej lokalizacji strony (nowa lokalizacja będzie widoczna na pasku adresu). Jedynym sposobem uniknięcia tego jest dodanie sandboxatrybutu bez wartości allow-top-navigation. Na przykład <iframe sandbox="allow-forms allow-scripts" ...>. Niestety, piaskownica zawsze wyłącza również wszystkie wtyczki. Na przykład treści YouTube nie można umieścić w piaskownicy, ponieważ odtwarzacz Flash jest nadal wymagany do przeglądania całej zawartości YouTube. Żadna przeglądarka nie obsługuje korzystania z wtyczek i jednocześnie nie zezwala na nawigację na najwyższym poziomie.
Należy pamiętać, że X-Frame-Options: DENYchroni również przed renderowaniem wydajnościowym atakiem kanału bocznego, który może odczytywać zawartość z różnych źródeł (znane również jako „ Ataki synchronizacji doskonałe pod kątem pikseli ”).
Fajnie, ale nie powinno "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."być przeformułowywane w kierunku dokumentu (nadrzędnego) zawierającego lukę XSS w dokumencie (podrzędnym) w ramce iframe?
Shuzheng
@Shuzheng luka działa w obie strony, a jeśli używasz <iframe>na stronie, pozwala rozszerzyć podatność z treści w ramce iframe na dokument hosta. Pytanie dotyczyło <iframe>bycia niebezpiecznym i jeśli dokument hosta ma lukę XSS, naprawdę nie potrzebujesz tego <iframe>elementu.
Mikko Rantalainen
13
Zakładam międzydomenową ramkę iFrame, ponieważ przypuszczalnie ryzyko byłoby niższe, gdybyś sam ją kontrolował.
Clickjacking to problem, jeśli Twoja witryna jest uwzględniona jako iframe
Zagrożony element iFrame może wyświetlać złośliwą zawartość (wyobraź sobie, że element iFrame wyświetla pole logowania zamiast reklamy)
Dołączony element iframe może wywoływać pewne wywołania JS, takie jak alert i prompt, co może denerwować użytkownika
Dołączona ramka iframe może przekierowywać przez location.href (yikes, wyobraź sobie ramkę 3p przekierowującą klienta z bankofamerica.com na bankofamerica.fake.com)
Złośliwe oprogramowanie wewnątrz ramki 3p (java / flash / activeX) może zainfekować użytkownika
„Niebezpieczne” i „Zagrożenie bezpieczeństwa” nie są pierwszymi rzeczami, które przychodzą na myśl, gdy ludzie wspominają o ramkach iframe… ale można ich użyć w atakach typu clickjacking .
Odpowiedzi:
Gdy tylko wyświetlasz zawartość z innej domeny, zasadniczo ufasz tej domenie, że nie będzie wysyłać złośliwego oprogramowania.
Nie ma nic złego w elementach iframe jako takich. Jeśli kontrolujesz zawartość iframe, są one całkowicie bezpieczne.
źródło
<iframe>element) ma odpowiedni styl i podpowiedzi, że ramka iframe zawiera niezaufaną zawartość, nie ma problemu. Oczywiście modulo to prawdziwe luki w przeglądarce. Krótko mówiąc,<iframe>jest tak samo bezpieczny jak plik<a href>.<iframe>tej samej domenie może spowodować zagrożenie bezpieczeństwa, jeśli zawartość ukrytego elementu iframe może zostać zmodyfikowana przez atakującego. Pozwoli to atakującemu na rozszerzenie ataku XSS wewnątrz ukrytego<iframe>na dowolną stronę w Twojej witrynie, która odnosi się do wspomnianej<iframe>treści. Aby uzyskać szczegółowe informacje, zobacz stackoverflow.com/a/9428051/334451 .IFRAMEElement może stanowić zagrożenie bezpieczeństwa, jeśli witryna jest osadzony wewnątrzIFRAMEna miejscu nieprzyjaznym . Więcej informacji o „clickjackingu” Google. Zauważ, że nie ma znaczenia, czy jesteś używać<iframe>czy nie. Jedyną prawdziwą ochroną przed tym atakiem jest dodanie nagłówka HTTPX-Frame-Options: DENYi nadzieja, że przeglądarka zna swoje zadanie.Ponadto element IFRAME może stanowić zagrożenie bezpieczeństwa, jeśli jakakolwiek strona w Twojej witrynie zawiera lukę XSS, którą można wykorzystać . W takim przypadku osoba atakująca może rozszerzyć atak XSS na dowolną stronę w tej samej domenie, którą można przekonać do załadowania
<iframe>na stronie z luką XSS. Dzieje się tak, ponieważ treść z tego samego źródła (tej samej domeny) ma dostęp do nadrzędnego DOM zawartości (praktycznie wykonuje JavaScript w dokumencie „host”). Jedyną prawdziwą metodą ochrony przed tym atakiem jest dodanie nagłówka HTTPX-Frame-Options: DENYi / lub zawsze prawidłowe kodowanie wszystkich danych przesłanych przez użytkownika (to znaczy nigdy nie ma luki XSS w witrynie - łatwiej powiedzieć niż zrobić).To jest techniczna strona problemu. Ponadto pojawia się problem z interfejsem użytkownika. Jeśli nauczysz swoich użytkowników, aby ufali, że pasek adresu URL nie powinien się zmieniać po kliknięciu linków (np. Twoja witryna używa dużego elementu iframe z całą rzeczywistą treścią), to użytkownicy nie zauważą niczego w przyszłości również w przypadku rzeczywistego bezpieczeństwa słaby punkt. Na przykład w witrynie może istnieć luka w zabezpieczeniach XSS, która umożliwia atakującemu ładowanie treści z wrogiego źródła w ramach elementu iframe. Nikt nie był w stanie stwierdzić różnicy, ponieważ pasek adresu URL nadal wygląda identycznie jak poprzednie zachowanie (nigdy się nie zmienia), a treść „wygląda” na prawidłową, mimo że pochodzi z wrogiej domeny żądającej danych logowania użytkownika.
Jeśli ktoś twierdzi, że użycie
<iframe>elementu w Twojej witrynie jest niebezpieczne i stwarza zagrożenie bezpieczeństwa, nie rozumie, co to<iframe>robi, lub mówi o możliwości wystąpienia<iframe>powiązanych luk w przeglądarkach. Bezpieczeństwo<iframe src="...">tagu jest równe<img src="..."lub<a href="...">tak długo, jak długo nie ma luk w przeglądarce. A jeśli istnieje odpowiednia luka, to może być możliwe, aby wyzwolić go nawet bez używania<iframe>,<img>lub<a>elementu, więc nie jest to warte rozważenia tego problemu.Należy jednak pamiętać, że zawartość z
<iframe>może domyślnie inicjować nawigację najwyższego poziomu . Oznacza to, że treść w ramach<iframe>może automatycznie otwierać łącze w bieżącej lokalizacji strony (nowa lokalizacja będzie widoczna na pasku adresu). Jedynym sposobem uniknięcia tego jest dodaniesandboxatrybutu bez wartościallow-top-navigation. Na przykład<iframe sandbox="allow-forms allow-scripts" ...>. Niestety, piaskownica zawsze wyłącza również wszystkie wtyczki. Na przykład treści YouTube nie można umieścić w piaskownicy, ponieważ odtwarzacz Flash jest nadal wymagany do przeglądania całej zawartości YouTube. Żadna przeglądarka nie obsługuje korzystania z wtyczek i jednocześnie nie zezwala na nawigację na najwyższym poziomie.Należy pamiętać, że
X-Frame-Options: DENYchroni również przed renderowaniem wydajnościowym atakiem kanału bocznego, który może odczytywać zawartość z różnych źródeł (znane również jako „ Ataki synchronizacji doskonałe pod kątem pikseli ”).źródło
"This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."być przeformułowywane w kierunku dokumentu (nadrzędnego) zawierającego lukę XSS w dokumencie (podrzędnym) w ramce iframe?<iframe>na stronie, pozwala rozszerzyć podatność z treści w ramce iframe na dokument hosta. Pytanie dotyczyło<iframe>bycia niebezpiecznym i jeśli dokument hosta ma lukę XSS, naprawdę nie potrzebujesz tego<iframe>elementu.Zakładam międzydomenową ramkę iFrame, ponieważ przypuszczalnie ryzyko byłoby niższe, gdybyś sam ją kontrolował.
źródło
„Niebezpieczne” i „Zagrożenie bezpieczeństwa” nie są pierwszymi rzeczami, które przychodzą na myśl, gdy ludzie wspominają o ramkach iframe… ale można ich użyć w atakach typu clickjacking .
źródło
iframe jest również podatny na skrypty międzyramkowe:
źródło