WEP lekcja #9 – Atak cross site request forgery (XSRF/CSRF)

W dzisiejszej #9 lekcji poznasz specyficzny atak o nazwie cross-site request forgery. W uproszczeniu atak ten polega na wysłaniu złośliwego żądania HTTP w imieniu ofiary. Przykładowo gdy audytor bezpieczeństwa odnajdzie lukę typu XSRF/CSRF, może spróbować nakłonić do wywołania danej akcji na stronie internetowej administratora lub zwykłego użytkownika strony (zmiana hasła, dodanie artykułu, zmiana ustawień witryny, zmiana podpisu na forum www itd) .

Jak wyżej wspomnieliśmy zaatakowana i oszukana ofiara, nieświadomie wywołuje pewną funkcjonalność strony. Tego typu luka często wykorzystywana jest z atakami typu XSS lub po prostu socjotechnicznymi. Wszystko zależy od budowy samej strony internetowej. O atakach XSS i języku JavaScript w połączeniu z CSRF dowiesz się z kolejnych lekcji.

Materiał filmowy o ataku Cross-site request forgery (CSRF)  – lekcja #9

Poniżej znajduje się dziewiąta lekcja szkoleniowa o atakach CSRF. Podatność została zaprezentowana w skrypcie szkoleniowym Damn Vulnerable Web Application (DVWA). Synonimiczną nazwą tego ataku często występującą w literaturze fachowej jest XSRF.

Zabezpieczenie przed CSRF / XSRF

Jako użytkownik po prostu zawsze się wylogowuj i nie używaj opcji „zapamiętaj mnie”. Unikniesz w ten sposób możliwości użycia Twojej wykradniętej w jakiś sposób sesji (np: w publicznych sieciach Wi-Fi). Drugą zaletą takiego postępowania jest oczywiście fakt, że w razie kliknięcia w złośliwy link z CSRF prowadzący do portalu na którym masz konto akcja się nie wykona automatycznie jeśli nie jesteś zalogowany.

Istnieje cały szereg metod, które utrudniają przeprowadzenie skutecznego ataku CSRF.

• Hasła jednorazowe uniemożliwiają osobie niepowołanej spreparowanie poprawnego żądania do serwera. Wymóg podania hasła udostępnionego wyłącznie dysponentowi konta na papierowej liście lub tokenie bądź też przesłanego SMSem na numer telefonu komórkowego praktycznie wyklucza powodzenie ataku CSRF.
• Im większe konsekwencje dla użytkownika niesie korzystanie ze strony, tym krótszy powinien być okres ważności zalogowania i dopuszczalny czas bezczynności.
• Żądania mające skutki uboczne mogą wymagać potwierdzenia, połączonego ew. z ponowną autoryzacją.
• Do każdego formularza można dodawać ukryte pole, zawierające liczbę pseudolosową, która musi zostać przekazana wraz z żądaniem wykonania akcji. Ignorowanie żądań, którym brakuje ukrytej wartości bądź gdy nie pokrywa się ona z liczbą zachowaną po stronie serwera, utrudnia spreparowanie ataku.
• Zamiast liczby pseudolosowej przesłać można zawartość ciasteczka służącego do uwierzytelnienia i porównać je z wartością przesłaną w nagłówku żądania HTTP oraz tą zapisaną po stronie serwera. Metoda ta opiera swoje bezpieczeństwo na zasadzie same origin policy, która gwarantuje, że wartość ciasteczka dostępna jest jedynie dla skryptów pochodzących z oryginalnej strony. Zwrócić należy jednak uwagę na to, że odpowiednio spreparowany skrypt może zostać umieszczony w serwisie przy pomocy ataku XSS.

Poniższe metody zapewniają jedynie prowizoryczne zabezpieczenie.

• Przesłanie do serwera spreparowanej zawartości formularza opartego na metodzie GET jest znacznie prostsze niż wykonanie tego samego zadania dla formularza opartego na metodzie POST, nie jest jednak niemożliwe, jeśli przeglądarka atakowanej osoby ma włączoną obsługę JavaScriptu. Nie zmienia to faktu, że stosowanie metody POST do żądań powodujących skutki uboczne jest jednym z zaleceń protokołu HTTP.
• Każdorazowe sprawdzanie czy pole Referer nagłówka żądania HTTP zawiera oryginalną domenę, w której działa aplikacja, również nie gwarantuje jej bezpieczeństwa, ponieważ JavaScript umożliwia atakującemu dowolnie kształtować nagłówek żądania.

Źródło: wikipedia.org

Użyty złośliwy link z atakiem cross site requests

Poniżej w skrypcie znajduje się zaznaczone miejsca z parametrami metody GET password i password_conf, które są podatne na atak CSRF.

Zadanie domowe z ataków CSRF i PHP

-> Zadanie 1

Poniżej został udostępniony Tobie kod umożliwiający administratorowi strony zmianę jej wyglądu. Po zalogowaniu się (admin/1234) spróbuj wpisać w formularzu inny kolor html w celu zrozumienia idei skryptu. Następnie utwórz nowy folder na na swoim serwerze XAMPP i zapisz w nim poniższe dwa następujące pliki. Przeanalizuj pobieżnie kod, znajdź w nim i wykorzystaj podatność CSRF. Wygrywasz jeśli znajdziesz podatny link i zmienisz za pomocą CSRF kolor strony na czerwony.

Uwaga! W języku PHP pojawia się kilka nowych funkcji, możesz korzystać z wyszukiwarki internetowej w celu ich pobieżnego zrozumienia.

Plik zaloguj.php:

<!DOCTYPE html>
<HTML>
    <HEAD>
        <META charset="UTF8">
    </HEAD>
    <?php
    if (isset($_GET['kolor'])) {
        $fp = fopen("kolor.txt", "w");
        $tekst = fwrite($fp, $_GET['kolor']);
        fclose($fp);
    }
    $fp = fopen("kolor.txt", "r");
    $tekst = fread($fp, 32);
    fclose($fp);
    echo('<BODY id="tresc_body" bgcolor="' . $tekst . '">');
    ?>

    <form action="zaloguj.php" method="POST">
        Login: <input type="text" name="login">
        Haslo: <input type="text" name="haslo">
        <input type="submit">
    </form>

    <?php
    $login = $_POST['login'];
    $haslo = $_POST['haslo'];

    if ($login == 'admin' && $haslo == '1234') {
        echo('Czesc admin! Wpisz kolor strony:');
        echo('<form action="zaloguj.php" method="GET"><input type="text" name="kolor">
		  <input type="submit">
	      </form>');
    } else {
        echo('Nie zalogowano!');
    }
    ?>
</BODY>
</HTML>

Plik kolor.txt:

yellow

http://192.168.0.14/kolor/zaloguj.php?kolor=TUTAJ_CSRF

Podsumowanie o atakach na podatność DVWA XSRF

Jak widzisz podatność CRSF atak jest bardzo łatwa w użyciu. Może posłużyć napastnikowi np. do zdalnej zmiany pewnych ustawień strony internetowej. Musisz wiedzieć, że badając bardzo rozbudowane skrypty stron internetowych Twoje zadanie jako audytora bezpieczeństwa jest utrudnione. W tego typu web aplikacjach po prostu w pasku adresu pojawia się multum parametrów GET (często jeden od drugiego zależny) i musisz wtedy stać się prawdziwym eksperymentatorem. Podatność nie dotyczy tylko parametrów przekazywanych w pasku adresu. Bardziej zaawansowane osoby mogą pokusić się o napisanie w języku JavaScript funkcji wysyłającej w tle zapytanie HTTP POST, jeśli akurat w tej metodzie występuje CRSF.

Oczywiście jeśli znasz wersje danego skryptu lub wtyczek których używa (istnieją programy do ich wstępnej identyfikacji np: wtyczka Wappalyzer) to możesz pokusić się o poszukanie informacji na temat znanych już luk w sieci Internet. Najbardziej hardkorowi gracze oczywiście analizują kod źródłowy strony klienta ręcznie niczym programista szukający błędów w kodzie. Jeśli chcesz być na bieżąco to wbijaj na naszego fejsa #HakerEduPL no i pytaj i komentuj. Dzisiaj byłoby to na tyle, Powodzenia w pracy domowej ;-)!