Cross-site scripting czyli atak XSS

Sty 24
2010

rakietaMimo, iż dziury wykorzystujące atak typu XSS można bardzo łatwo załatać to pojawiają się one na wielu stronach. Błąd tego typu można spotkać wszędzie tam gdzie przetwarzane i wyświetlane są dane wprowadzane przez użytkownika, jak na np. najczęstszych celach agresorów czyli księgach gości. Jak można wywnioskować XSS polega na niedostatecznym filtrowaniu danych.

Teoria

Załóżmy, że znaleźliśmy w Google stronkę z księgą gości. Wiedząc, że może ona być podatna na atak typu XSS przetestujemy jej poziom filtracji danych. W takich skryptach najczęściej wystarczy podać nick oraz treść. Aby sprawdzić podatność skryptu na atak w obu polach wpiszmy

<u><b>Test XSS</b></u>

Jeśli dane nie będą filtrowane to w miejscu, gdzie powinien wyświetlić się nasz wpis pojawi się podkreślony oraz pogrubiony napis Test XSS. W przeciwnym wypadku, jeśli Administrator zadbał o bezpieczeństwo księgi w wpisie pojawią się nasze tagi (encje) HTML.

Praktyczny przykład „dziurawego” skryptu

Posiadając już jakieś pojęcie o XSS przeanalizujmy przykładowy niezabezpieczony skrypt księgi gości oparty o plik tekstowy.

<?php
/*
Autor: Komeniusz
Plik ksiega.txt nalezy utworzyc recznie nadajac mu uprawnienia do odczytu i zapisu
*/
echo'
<form action="" method="post">
<table border="2">
<tr><td>Nick:</td><td><input type="text" name="tytul" size="40" /></td></tr>
<tr><td>Wpis:</td><td>
   <textarea name="wpis" cols=60 rows=10 wrap="virtual"></textarea>
</td></tr>
</table>
<input type="submit" value="Wpisz sie!" />
</form>
';
 
$tytul = $_POST['tytul'];
$wpis = $_POST['wpis'];
 
if($tytul && $wpis) { // są informacje do wpisania
 
 // skomplikowany wpis
 $ksiega[0] = "<h3>".$tytul."</h3><p>".$wpis."</p>rn";
 
 if (file_exists("ksiega.txt")) { // już jest założony plik
  $i = 1;
  $plik = fopen ("ksiega.txt", "r+"); //odczyt danych
  flock ($plik, 2);
  while (!(feof($plik))) {
   $ksiega[$i++] = fgets ($plik, 2048);
  }
  $ilosc=$i;
  fseek ($plik, 0);                 // powrót do początku pliku
  for ($i=0; $i<$ilosc; $i++) {         // i zapis
   fputs ($plik, "$ksiega[$i]");
  }
 flock ($plik, 3);
 fclose ($plik);
 }
 else {                     // nie ma pliku, więc tworzymy nowy
  $plik = fopen ("ksiega.txt", "w+");
  flock ($plik, 2);
  fputs ($plik, "$ksiega[0]");
  flock ($plik, 3);
  fclose ($plik);
 }
}
 
echo'<h2>Ksiega gosci</h2><hr />';
if(file_exists("ksiega.txt")) {  //jesli plik istnieje
 $plik = fopen ("ksiega.txt", "r");
 while(!(feof($plik))) {
  echo(fgets ($plik, 2048));
 }
}
?>

W pole nick oraz treść wpiszmy nasz kod sprawdzający podatność skryptu na atak. Jak można zauważyć na stronie nie pojawiły się nasze tagi HTML, a wpisane dane zostały pogrubione i podkreślone, czyli skrypt na prawdę jest dziurawy.

Zachodzi pytanie – Jak można to wykorzystać? No cóż, poza kradzieżą plików cookies wykorzystując kod JavaScript można w widowiskowy i spektakularny sposób zakryć treść strony pisząc na niej „Hacked by XXX”. Wystarczy tylko wysłać odpowiednio spreparowany kod HTML z DIV’em absolutnym.

<div style=”text-align:center;color:#FF0000;background:#000000;position:absolute;top:0;left:0;right:0; bottom:0;padding:0;margin:0;height:100000px;z-index:101;padding-top:50px;font-size:50px;font-family:Verdana;”>

Hacked by XXX

</div>

Gdzie XXX tam oczywiście nick agresora. Zademonstrowany wyżej sposób to udany atak typu XSS na księgę gości. Błąd ten można oczywiście znaleźć w innych skryptach, takich jak komentarze, czy nawet rejestracja podając w nazwie nicka spreparowany kod. DIV absolutny znajduje także swoje zastosowanie podczas dodawania ‚newsa’ z poziomu Panelu Administratora poprzez osobę do tego niepowołaną.

Na atak podatne są tak samo dane wysyłane metodą POST jak i GET. Żywy przykład na to zademonstruje na przykładzie strony Ogólnopolskiego Konkursu Informatycznego, który w trakcie pisania tego artykułu jest jak najbardziej możliwy i aktualny.

http://oki.edu.pl/index.php?site=newsletter&usun=<b><u>Atak XSS</u></b>

XSRF

XSS posiada także swojego młodszego brata, nazwanego XSRF (Cross-site request forgery). W przeciwieństwie do XSS, atak XSRF nie pozostawia widocznych zmian na stronie. Polega on najczęściej na nieświadomym wykorzystaniu uprawnień administratora w celu przejęcia serwisu.

Jak się zabezpieczyć?

Jak widać z pozoru niewinna luka, a może wyrządzić wiele szkód. Jednym z sposobów zabezpieczenia się jest użycie funkcji htmlspecialchars() przy każdej wyświetlanej informacji. Zamieni ona tagi HTML (<, >) na encje, które nie zostają zinterpretowane przez przeglądarkę jako kod do wykonania (pogrubienia/podkreślenia), a jako zwykły znak do wyświetlenia.

Źródła

Więcej na temat ataków XSS oraz XSRF można poczytać na Wikipedii oraz znaleźć przydatne informacje w Google.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *