Cross- Site Scripting ( XSS ) to rodzaj luki w bezpieczenstwie, która jest bardzo rozpowszechniona. Pozwala ona atakującemu wstawić złośliwy kod ( JavaScript ) w przeglądarce internetowej poprzez wykorzystanie niezabezpieczonej aplikacji internetowej. Atakujący może dostarczyć szkodliwy kod w wiele różnych sposobów. Może nakłonić użytkownika do kliknięcia na link (tak zwany reflected / non-persistent XSS ), lub poczekać aż użytkownik odwiedzeni stronę internetową zawierającą jego złośliwy kod (stored / persistent XSS ).
Co mają do tego irytujące wyskakujące okienka ( pop-ups) z numerem 1 czy innym tekstem ? To prosty sposób, w jaki można udowodnić, że aplikacja jest wrażliwa na atak XSS. Tylko nie daj się zwieść ich niewiności, atakami XSS można osiągnąć wiele więcej.
Hacker może wykraść twoje ciasteczka internetowe, ktore są używane do uwierzytelnionia Cię na stronach internetowych !
Atakujący może dodać sfałyszowone stron logowania do aplikacji w celu skłonienie użytkownika do ujawnienia jego nazwy użytkownika i hasła.
Ataki XSS są w stanie, bez twojej wiedzy, przekierować twoją przeglądarkę do złośliwych witryn internetowych. Celem jest nakłonienie użytkownika do ujawnienia poufnych informacji, takich jak jego dane bankowe.
XSS może być nawet użyty do ominięcia środków bezpieczeństwa, które są wbudowane w aplikację czy przeglądarkę internetową, aby cię chronić .
Możliwości są niemal nieograniczone. Przejąć kamerę internetową ? Tak ! Podsłuchiwać używając twojego mikrofonu na komputerze ? Jasne !Do zaawansowanych ataków czesto jest wykorzystywane narzedzie zwane The Browser Exploitation Framework (BeEF).
The Apache Foundation, twórcy jednego z najbardziej popularnych serwerów aplikacji WWW mieli bezpieczeństwo swoich serwerów skompromitowane za pomocą ataku XSS .
Atak XSS na oficjalnym forum popularnego systemu operacyjnego Linux , Ubuntu , pozwolił napastnikowi pobrać nazwy użytkowników , adresy e-mail i hasła do 1.820.000 swoich użytkowników.
Ataki XSS zazwyczaj skupiają się na użytkownikach aplikacji i ich lokalnych sieciach , jednak , jak widać na powyższych przykładach, gdy użytkownicy ci mają status administratora, same serwery internetowe są również zagrożone.
Luki XSS są odkrywane w serwisach Facebook , Yahoo , Google, Twitter i innych witrynach o wysokim profilu codziennie. Często przez niezależnych specjalistów w bezpieczeństwie komputerowym uczestniczących w tak zwanych bug bounties.
Oto lista innych hacków za pomocą XSS - https://www.google.com/fusiontables/DataSource?snapid=S1158702BBoV
Zwracaj uwagę na co klikasz. Nawet niegroźnie wyglądający link, może zawierać szkodliwy skrypt.
Wyloguj się z witryn internetowych, gdy skończysz z nimi, to utrudnia hackerom wykraść "cookies".
Cross-site scripting występuje, gdy dane wprowadzane przez użytkownika na stronę internetową, nie są filtrowane i / lub odpowiednio zakodowane .
Na przykład, załóżmy że użytkownik dostarcza swoją nazwę użytkownika do zalogowania, a następnie aplikacja wyświetla ten login bez filtrowania i / lub kodowania. Co się stanie, gdy nazwa użytkownika zawiera znaki HTML ? Przeglądarka nie będzie w stanie odróżnić co jest loginem, a co jest kodem strony internetowej. Kod HTML czy JavaScript użytkownika zostanie umieszczone w kodzie twojej strony ! Upewnij się, że filtrujesz wprowadzane znaki, nazwa użytkownika nie powinna zawierać innych znaków niż alfa-numeryczne. W tym celu możesz użyć white-listing.
Użyj odpowiedniego kodowania ! Jeśli nazwa użytkownika może wystąpić gdzieś w kodzie HTML twojej strony, zakoduj wszystkie znaki w formacie HTML. W ten sposób przeglądarka będzie wiedzieć, co ma być wyświetlany jako HTML a co nie. To nie wszystko na temat kodowania. Odwieź poniższe linki w celu uzyskania dodatkowych informacji.
Przeskanuj swoją aplikację pod kontem problemów XSS. Istnieje wiele automatycznych skanerów bezpieczeństwa aplikacji internetowych, które mogą wykryć problemy XSS. Na przykład OWASP ZAP.
Sprawdź czy ciasteczka uwierzytelniające na twojej stronie mają ustawione flagi HttpOnly i Secure. HTTPOnly mówi przeglądarce, że cookies nie są dostępne dla JavaScriptu, co pomaga ochronić je przed atakami XSS. Z kolei flaga Secure nie pozwala na ich wysyłanie poza protokołem HTTPS.
Nagłówek HTTP o nazwie Content Security Policy (CSP) może być ustawiony przez serwer WWW żeby określić przeglądarkom internetowym gdzie obsługa JavaScript jest dozwolona. CSP używa white-listing.
Wreszcie , dlaczego nie zainstalować Web Application Firewall ( WAF ) , takich jak mod_security Open Source ! WAF daje aplikacji dodatkową warstwę obrony przed tymi atakami, aczkolwiek nie powinien być używany jako jedyna ochrona jakoże żaden WAF nie jest doskonały.
Dwa typy XSS zamieszczone na tej stronie (Reflected and Stored) nie są jedynymi rodzajami !
Jeśli chcesz dowiedzieć się wiecej Open Web Application Security Project (OWASP) jest doskonałym źródłem informacji dla wszystkich rzeczy związanych z bezpieczeństwem aplikacji internetowych. Sprawdź ich artykuł na temat XSS i ich XSS Prevention Cheat Sheet. Aby uzyskać informacje na temat innych rodzajów luk bezpieczeństwa w aplikacjach internetowych, zapoznaj się z OWASP Top 10.
Dziękujemy za twój czas,
Ryan Dewhurst & Thomas MacKenzie
---
Celem tej strony było przestawienie tematu w prostym do zrozumienia jezyku.
Konstrukcja tej strony została zainspirowana przez http://justinjackson.ca/words.html
---
Thanks to @JanZamoysky for this translation. English version here.