Articles

DOM based Cross Site Scripting

Posted on

mniej znana technika XSS

  • DOM oznacza Document Object Model
  • XSS oznacza cross – Site scripting
  • główna różnica między XSS bazującym na DOM a innymi lukami XSS polega na tym, że ładunek jest osadzony po stronie klienta, a nie po stronie serwera
  • luki XSS bazujące na DOM muszą więc być zapobiegane po stronie klienta

przede wszystkim luki w zabezpieczeniach Cross-site scripting (XSS) stał się znany dzięki Cert Advisory CA-2000-02 (złośliwe tagi HTML osadzone w żądaniach internetowych klientów), chociaż te luki były wcześniej wykorzystywane. Tak więc XSS istnieje już od jakiegoś czasu. I jak można się spodziewać, istnieje już wiele artykułów laboratoriów na ten temat, w tym Cross – Site Scripting-niedoceniane niebezpieczeństwo i Cross-Site – Scripting i zapobieganie wstrzykiwaniu skryptów-krótki przewodnik. Jednak ten artykuł koncentruje się w dużej mierze na DOM oparte cross – Site scripting, termin po raz pierwszy ukuty w 2005 roku przez Amit Klein. Nagłośnił definicję DOM based cross – site scripting (XSS) i wyodrębnił ją z innych luk w zabezpieczeniach skryptów między witrynami. Aby zrozumieć Skrypty między witrynami oparte na DOM, musisz najpierw głębiej zrozumieć DOM.

co to jest DOM?

Document Object Model jest interfejsem programu, który definiuje strukturę dokumentów. Istotne dla naszych celów jest to, że DOM zapewnia obiektową reprezentację dokumentów HTML, w szczególności:

  • jak element HTML jest reprezentowany jako obiekt
  • jakie atrybuty elementu HTML są
  • jakie metody mogą być używane, aby uzyskać dostęp do elementu HTML
  • jakie zdarzenia elementu HTML są

oznacza to, że DOM określa, w jaki sposób elementy HTML można znaleźć, dodać, zmienić lub usunąć w przeglądarce. Oznacza to, że DOM oferuje możliwość manipulowania stronami HTML. Obecnie JavaScript jest zwykle używany do tego rodzaju manipulacji.

należy zauważyć, że każda przeglądarka implementuje standard DOM inaczej. Może to mieć wpływ na to, czy konkretny atak DOM XSS działa w konkretnej przeglądarce.

co to jest XSS oparty na DOM?

Luka XSS oparta na DOM pojawia się, gdy DOM jest używany do generowania dynamicznej zawartości zawierającej dane wejściowe użytkownika, które mogą być przetwarzane bez sprawdzania. Ten rodzaj ataku jest przeprowadzany za pomocą JavaScript w przeglądarce użytkownika. Tutaj lokalizacje, które (złośliwe) dane wejściowe użytkownika wprowadzają do drzewa DOM, są oznaczone jako źródła. Lokalizacje, w których (złośliwe) wprowadzanie danych przez użytkownika może być wykonywane w DOM, są oznaczone jako sink.

przykład prostej luki w skryptach cross-site:

<!DOCTYPE html><html> <body> <script> var source = "Hello " + decodeURIComponent(location.hash.split("#")); //Source var divElement = document.createElement("div"); divElement.innerHTML = source; //Sink document.body.appendChild(divElement); </script> </body></html>

luka może zostać wywołana na przykład za pomocą następującego żądania GET:

GET www.vulnerable-website.example#<img src="test" onerror="alert('XSS')">

widzimy, że ten przykład wymaga użycia metody decodeURIComponent. Dzieje się tak dlatego, że współczesne przeglądarki kodują znaki specjalne w adresie URL, a atak nie działałby bez dekodowania tych znaków specjalnych. Zawartość zmiennej sourcejest dodawana do elementu div za pomocą innerHTML. Jest to problematyczny element w kodzie, ponieważ jego przypisanie do innerHTML powoduje, że dołączona do niego wartość jest interpretowana jako HTML. Jeśli wartość zawiera JavaScript, jest to również wykonywane.

należy zauważyć, że nie zmienia to odpowiedzi serwera. Złośliwa modyfikacja pojawia się tylko wtedy, gdy kod JavaScript jest wykonywany po stronie klienta, który następnie zmienia DOM.

Należy zauważyć, że w żadnym wypadku nie jest to lista wyczerpująca.

Źródła

  • dokument.URL
  • polecający
  • lokalizacja
  • lokalizacja.href
  • lokalizacja.Szukaj
  • lokalizacji.hash
  • lokalizacja.pathname

Sinks

  • eval
  • setTimeout
  • setInterval
  • dokument.napisz
  • element.innerHTML

zapobieganie XSS opartemu na DOM

ponieważ istnieją przypadki, w których ładunek nigdy nie dociera do serwera, zapobieganie tej luce nie jest zadaniem po stronie serwera. Przykład powyżej jest jednym z takich przypadków. Powodem jest to, że zawartość, która pojawia się po znaku#, nie jest wysyłana przez przeglądarkę do serwera.

pierwszym i najważniejszym zaleceniem jest unikanie używania danych kontrolowanych przez użytkownika do dynamicznego generowania treści, gdy tylko jest to możliwe. Jeśli jest to całkowicie nieuniknione, najlepszym sposobem zapobiegania XSS opartym na DOM jest użycie bezpiecznych metod wyjściowych (sink), które uniemożliwiają wykonanie złośliwie osadzonego kodu. W powyższym fragmencie kodu jedynym sposobem, aby Kod był bezpieczny, jest zastąpienie .innerHTML .textContent. Dzieje się tak dlatego, że – w przeciwieństwie do innerHtml – elementy HTML w metodzie textContent nie są wykonywane.

oparty na DOM XSS Prevention Cheat Sheet od OWASP zawiera wiele przydatnych wskazówek dotyczących tworzenia bezpiecznych dynamicznych stron internetowych z JavaScript. Znajdziesz tam również opisy kodowania zależnego od kontekstu, które jest wymagane, gdy nie można przełączyć się na bezpieczną metodę wyjścia.

różnice w stosunku do innych luk w zabezpieczeniach XSS

najważniejszą różnicą jest to, gdzie atak jest osadzony w kodzie. W przeciwieństwie do innych luk w zabezpieczeniach skryptów między witrynami, kod nie jest osadzony po stronie serwera, ale po stronie klienta. Oznacza to, że ładunek nie może być znaleziony w kodzie odpowiedzi. Luki w zabezpieczeniach XSS oparte na DOM można zatem wykryć tylko w czasie wykonywania lub sprawdzając DOM witryny.

w większości przypadków znalezienie luk w zabezpieczeniach XSS opartych na DOM nie jest łatwe. Pomocne podejście wykorzystujące statyczne podejście do analizy kodu jest opisane w artykule Burp based-xss.

o autorze

Andrea Hauser

Andrea Hauser ukończyła studia licencjackie z informatyki na Uniwersytecie Nauk Stosowanych w Rapperswil. Swoją obraźliwą pracę koncentruje na testowaniu bezpieczeństwa aplikacji internetowych i realizacji kampanii socjotechnicznych. Jej głównym celem badawczym jest tworzenie i analizowanie deepfakes. (ORCID 0000-0002-5161-8658)

linki

  • http://www.webappsec.org/projects/articles/071105.html
  • https://support.portswigger.net/customer/portal/articles/2325926-using-burp-scanner-to-test-for-dom
  • https://www.cert.org/historical/advisories/CA-2000-02.cfm
  • https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
  • https://www.w3.org/DOM/

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.