Dlaczego elementy iframe są uważane za niebezpieczne i stanowią zagrożenie dla bezpieczeństwa?

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?

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.

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 ”).

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 .

iframe jest również podatny na skrypty międzyramkowe:

• https://www.owasp.org/index.php/Cross_Frame_Scripting