Mimo, 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.

[codesyntax lang=”php”]

<?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));
 }
}
?>

[/codesyntax]

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.