Bezpieczeństwo aplikacji internetowych. Target="_blank" podatność na ataki

Niedawno pisaliśmy o bezpieczeństwo aplikacji internetowych, jeśli chodzi o luki XSS. Tym razem chcemy zwrócić uwagę na inne niebezpieczeństwo.

Podatność omawiana w tym artykule towarzyszy nam od dawna, a ze względu na swoją prostotę jest często niedoceniana lub nawet nieznana przez niektórych. programiści aplikacji internetowych.

Prawie każda aplikacja internetowa zawiera linki, które po kliknięciu otwierają się w nowej karcie, aby nie zamykać karty z oryginalną stroną. Jest to preferowane zachowanie, ponieważ twórcy chcą, aby użytkownik spędził jak najwięcej czasu w aplikacji.

Atakiem wykorzystującym tę lukę jest tak zwany "odwrotny tabnabbing". Jest to atak, w którym strona połączona ze stroną docelową jest w stanie zastąpić tę stronę, na przykład, witryną phishingową.

Scenariusz ataku

1. Załóżmy, że ofiara korzysta z Facebooka, który jest znany z otwierania linków przez target="_blank",
2. Utwórz fałszywą stronę wirusową,
3. Stworzenie strony phishingowej, która wygląda jak strona logowania na Facebooku,
4. Umieść poniżej kod na stronie wirusowej, np. poprzez znalezioną lukę XSS
   window.opener.location = 'https://phishing-website/facebook.com';
5. Ofiara klika link na Facebooku do strony z wirusem,
6. Zawirusowana strona przekierowuje kartę Facebooka na stronę phishingową z prośbą o ponowne zalogowanie się.

Możemy więc zmienić kartę nadrzędną z zainfekowanej strony docelowej za pomocą obiektu okna z Web API. Zazwyczaj atak polega na równoległym wykorzystaniu kilku wykrytych luk i oszustw phishingowych.

Problem

Kiedy otwieramy nową kartę w przeglądarce za pomocą linku z rozszerzeniem target="_blank" mamy dostęp do naszego "referrera" z nowej zakładki. A dokładniej, do atrybutu otwieracz właściwość Okno który zwraca odwołanie do okna, które go otworzyło, czyli naszej strony nadrzędnej.

Jest to spowodowane zachowaniem Window.open() function. Mając dostęp do tego atrybutu, możemy łatwo zastąpić naszą stronę nadrzędną. Należy pamiętać, że niektóre nowoczesne przeglądarki mogą window.opener w zakładce docelowej jako null aby zapobiec takiemu zachowaniu.

Przykładowy kod

<code> <a href="https://github.com" target="_blank">Przejdź do GitHub - zainfekowany link</a>
const
 if (link)
   link[0].onclick = () => {
     if (window) window.opener.location = 'https://stackoverflow.com'
   }

Powyżej widać zainfekowany link, który początkowo otwiera nową kartę ze stroną GitHub, ale w międzyczasie zmienia naszą stronę "nadrzędną" na stronę Stackoverflow.

Przykład na żywo

1. Łącza HTML

Dodaj rel="noopener noreferrer" do <a> tag.

The rel definiuje relację między połączonym zasobem a bieżącym dokumentem.

noopener nakazuje przeglądarce nawigację do celu bez przyznawania dostępu do rodzica, który go otworzył. Zakładka docelowa Window.opener będzie null.

noreferrer uniemożliwia przeglądarce, podczas nawigacji do celu, wysyłanie do strony nadrzędnej adresu lub innej wartości jako referrer poprzez referent Nagłówek HTTP. Należy zauważyć, że ta nazwa nagłówka HTTP jest celowo błędnie zapisana jako "referrer".

2. JavaScript linki

Dla JavaScript Window.open można dodać wartości noopener i noreferrer w windowFeatures parametru Window.open funkcja, ale różne przeglądarki mogą reagować inaczej, dlatego zaleca się wykonanie funkcji Window.opener jak null po użyciu Window.open() funkcja.

Czytaj więcej:

Rails API i CORS. Szczypta świadomości

Strategie pobierania danych w NextJS

7 powodów, dla których twój sklep internetowy potrzebuje Magento

Jeśli uważasz ten artykuł za interesujący, śledź Łukasza na Githubie: https://github.com/twistezo