Atak XSS (Cross-site scripting)

W przeciwieństwie do innych ataków, XSS (Cross-site scripting) jest wykonywany po stronie przeglądarki. Jest to atak na klienta podatnej aplikacji WWW, co w cale nie znaczy, że nie zagraża on samej aplikacji, a tym bardziej dane znajdujące się po jej stronie. Polega on na wstrzyknięciu do przeglądarki fragmentu kodu języka skryptowego (np. JavaScript) i jego wykonanie.

Najczęściej prezentowanym efektem takiej podatności jaki możemy zobaczyć w różnych przykładach jest "alert()", czyli wstrzyknięcie do kodu strony funkcji JavaScript powodującej wyświetlenie okienka z komunikatem i przekazanie go do przeglądarki gdzie zostanie wykonany.

Udany atak typu XSS
W powyższym przykładzie nasz kod został przekazany w adresie URL strony i na niej wyświetlony.

[code]
 http://www.atakowanastrona.pl/?imie=<script>alert('XSS')</script>"
[/code]

Oczywiście, w tym przypadku intruz tak naprawdę musi nakłonić swoja ofiarę do wejścia na powyższy adres, co wbrew pozorom nie musi być takie trudne. Często do tego celu są wykorzystywane równolegle błędy w komunikatorach, serwisy skracające linki lub fałszywe bądź inne zainfekowane strony, które potajemnie przekierowują nas w tle na taki adres.

Jeszcze groźniejszym przykładem ataku XSS jest jego odmiana Stored lub też inaczej nazywany Persistent. W przypadku tego ataku kod jest na stale osadzony w zainfekowanej stronie przez co w najgorszym przypadku każdy odwiedzający ją użytkownik staje się ofiarą ataku. Poza wspomnianym już wcześniej atakiem SQL Injection za pomocą którego można niekiedy  zmodyfikować informacje w bazie zamieszczając również i fragment skryptu XSS, potencjalnym zagrożeniem są wszelkie formularze kontaktowe, komentarze lub inne dające możliwość użytkownikowi wprowadzić i zapisać informacje w bazie lub na stronie.

Wbrew pozorom ataki XSS należą do bardzo groźnych. Podatność ta zagraża zarówno samym serwisom jak i ich klientom. Załóżmy, że intruz pomyślnie wstrzyknie do formularza kontaktowego skrypt XSS. Zostanie on następnie wyświetlony przez pracownika obsługującego CRM w czego efekcie jego przeglądarka przekaże natychmiast intruzowi aktywny identyfikator sesji zamieszczony w Cookie. Korzystając z niego intruz może już bez logowania dostać się do panelu administracyjnego CRM i wykraść wszystkie zawarte w nim informacje.

Aby uniknąć takiego ataku warto zabezpieczyć swoją aplikację już na etapie jej tworzenia. Wdrożenie odpowiednich mechanizmów walidujących wprowadzane dane i odpowiednio je kodujących to jeden z pierwszych kroków. Pamiętajmy jednak, że w wielu przypadkach część elementów aplikacji może sie w końcowym efekcie niezabezpieczona odpowiednio lub jeśli wykorzystywane do tego celu jest gotowe rozwiązanie np. Wordpress lub Joomla, to i w nich prędzej czy później może zostać wykryta podatność XSS. Najlepszym dowodem na to są informacje publikowane przez twórców np.  https://wordpress.org/news/2015/08/wordpress-4-2-4-security-and-maintenance-release/

W takiej sytuacji najlepszym rozwiązaniem jest skorzystanie z ochrony GreyWizard w ramach której dostępny jest zaawansowany Web Application Firewall. Korzystając z przygotowanych reguł jak i zaawansowanych algorytmów WAF analizuje, a następnie blokuje intruzów chcących przeprowadzić między innymi atak typu XSS na chroniony serwis.

Skutecznie zablokowana próba ataku XSS

Brak komentarzy :

Prześlij komentarz