Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Tecniche: Cross Site Scripting

Capire e difendersi dal Cross Site Scripting, uno degli attacchi maggiormente utilizzati per manipolare le applicazioni Web. Esempi di codice e contromisure da adottare
Capire e difendersi dal Cross Site Scripting, uno degli attacchi maggiormente utilizzati per manipolare le applicazioni Web. Esempi di codice e contromisure da adottare
Link copiato negli appunti

La grande diffusione dei siti a contenuto dinamico che utilizzano
linguaggi lato server (come ASP e PHP) ha favorito lo sviluppo di particolari
tecniche di hacking ideate per colpire gli utilizzatori delle applicazioni
web. Una delle tecniche più conosciute prende il nome di Cross
Site Scripting
, spesso abbreviata con CSS (oppure XSS, per
non confondere la sigla con quella dei fogli di stile nelle pagine web).

Il CSS permette ad un aggressore di inserire codice arbitrario
come input di una web application, così da modificarne il comportamento
per perseguire i propri fini illeciti. Se uno script consente questo
tipo di attacco, è facile confezionare un URL ad hoc e inviarlo
all'utente che sarà vittima del sotterfugio. All'utente, ignaro
di questa modifica, sembrerà di utilizzare il normale servizio
offerto dal sito web vulnerabile. Pagine web o e-mail sono i mezzi ideali
per portare a termine l'attacco.

I pericoli del Cross Site Scripting

Quando utilizziamo un servizio che richiede l'inserimento di username
e password, spesso questi dati vengono registrati sul nostro computer
sotto forma di Cookie (un file di testo) per non doverli
digitare ogni volta. Per ovvi motivi di sicurezza, i dati contenuti
nel cookie sono accessibili solo dal sito web che li ha creati. Ma supponiamo
che il sito in questione utilizzi una applicazione vulnerabile al CSS:
l'aggressore potrà iniettare un semplice JavaScript che legge
il cookie dell'utente e lo riferisce. Il browser dell'utente permetterà
la lettura, perchè in effetti il JavaScript viene eseguito da
un sito autorizzato a leggere il cookie!

Il risultato immediato è evidente: l'aggressore avrà accesso
al cookie e, a seconda delle informazioni contenute, sarà in
grado di leggere la nostra posta, oppure di utilizzare il nostro nickname
nel forum che frequentiamo (e i nostri privilegi, se ad esempio siamo
amministratori), e così via.

Oltre al danno, la beffa: il Cross Site Scripting solitamente richiede
un intervento attivo da parte della vittima per poter funzionare: anche
il click su un link in una pagina web o in un messaggio di posta elettronica
può nascondere insidie di questo tipo. Facciamo dunque attenzione
ai link sospetti: se contengono i tag <script>
all'interno, o se troviamo codice esadecimale (utilizzato perchè
viene interpretato normalmente dal server ma nasconde agli occhi dell'utente
gli indizi che potrebbero allarmarlo), pensiamoci due volte prima di
aprirli!

Qualsiasi tipo di applicazione web può essere a rischio, se non
implementa opportuni controlli sull'input degli utenti. Vediamo una semplice
classificazione in base all'origine del programma:

  • Script casalinghi:
    dei moderni linguaggi lato server permette la creazione di script
    da utilizzare sui siti web personali. Spesso però le tecniche
    basilari della programmazione sicura non sono conosciute e gli script
    offrono molti punti vulnerabili agli attacchi di CSS.
  • Applicazioni web diffuse:
    appositamente per essere diffuse e utilizzate in migliaia di siti
    (forum, chat, sistemi di gestione dei portali) solitamente sono sviluppate
    con un maggiore attenzione ai problemi della sicurezza. Ciò
    non esclude la scoperta periodica di nuove sviste nella programmazione
    che aprono le porte al Cross Site Scripting.
  • Server web:
    bug XSS quando riguardano i server web, applicazioni molto diffuse
    e che solitamente non lasciano presagire la vulnerabilità a
    questo tipo di attacco. L'unico vantaggio in questo caso è
    la possibilità di accorgersi tempestivamente dell'attacco in
    corso, tramite l'analisi dei log del server.
  • Esempi di attacchi reali

    Per meglio comprendere i meccanismi del Cross Site Scripting, vediamo
    due esempi reali riguardanti uno dei forum in PHP più diffusi e
    il server web di Microsoft. Per il primo esempio consideriamo l'advisory
    per vBulletin 2.2.6 e 2.2.7 pubblicata su NTBugtraq.

    Il forum in questione consente di interagire con il programma di messaggistica
    AOL Instant Messenger, ma il parametro "aim" dell'URL
    (che viene stampato poi nella pagina) non è filtrato in alcun modo.
    Proviamo dunque a inserire un JavaScript come valore della variabile e
    vediamo cosa succede:

    www.host.com/forum/member.php?s=&action=aimmessage&aim=<script>alert(document.cookie)</script>

    Lo script viene inserito nel codice html della pagina e quindi interpretato
    dal browser dell'utente. Il risultato sarà una popup contenente
    tutti i dati contenuti nel cookie salvato dal forum: username, password,
    ultima visita e così via. Anche se i valori sono in forma cifrata,
    possono essere utilizzati dall'aggressore per sostituirsi a noi.

    Sicuramente i tag all'interno dell'indirizzo possono destare sospetti.
    Ma se li sostituiamo con un più criptico codice esadecimale (ad
    esempio il tag <script> si traduce in %73%63%72%69%70%74) sarà
    più difficile che la vittima si accorga dell'inganno. Attenzione
    dunque agli indirizzi che presentano una quantità anomala di segni
    percentuale "%".

    Neanche i web server sono immuni dagli attacchi di Cross Site Scripting,
    anche se in questo caso si tratta di bug più difficili da scoprire
    e da sfruttare. Il server web di Microsoft IIS 5.0, uno
    dei più utilizzati, ha avuto in passato vari problemi con l'interpretazione
    delle estensioni supportate per default. Uno di questi riguardava la possibilità
    di un attacco XSS tramite la preparazione di un indirizzo URL molto lungo
    che il server non riusciva a gestire (SecurityFocus
    Bugtraq
    ) .

    Normalmente la richiesta di una pagina inesistente con estensione .IDC
    dovrebbe generare un errore di codice 404. Il bug però faceva in
    modo che il server restituisse una pagina di errore non standard, contenente
    l'intero URL richiesto senza alcun controllo sull'input. Come abbiamo
    visto, quando un JavaScript viene inserito in una pagina html, il browser
    dell'utente lo interpreta come se facesse parte della pagina originale.
    Bastava quindi inserire lo script all'interno dell'URL per vederlo eseguito:

    http://www.host.com/<long_buffer><script_da_eseguire>.idc

    http://www.host.com/<long_buffer><script>alert(document.cookie)</script>

    Il parametro <long_buffer> sta per un insieme di caratteri casuali,
    in modo che la lunghezza totale dell'URL superi i 334 caratteri. Questa
    è la lunghezza minima del buffer per la quale il server inizia
    a mostrare il comportamento anomalo. Consideriamo che il JavaScript è
    solo uno dei linguaggi che si possono iniettare nelle pagine tramite il
    CSS: anche VBScript, ActiveX, Flash si prestano al "gioco".

    Contromisure

    I bug riscontrati nelle applicazioni web solitamente vengono risolti in
    breve tempo e le patch sono integrate nelle versioni successive degli
    script. Per la falla di vBulletin che abbiamo analizzato è necessario
    scaricare una versione successiva del forum dal sito ufficiale di Jelsoft
    Enterprises
    .

    Per risolvere il bug di IIS 5.0 è necessario installare il Service
    Pack 3
    di Windows 2000 oppure eliminare l'estensione IDC dal mapping
    delle applicazioni nel pannello di controllo del servizio Internet Microsoft.

    Molti dei bug relativi al Cross Site Scripting possono
    essere risolti implementando una procedura di validazione dell'input
    negli script. Gli sviluppatori dovrebbero quindi cercare di essere sensibili
    ai temi della sicurezza, anche se non indispensabili al fine dell'applicazione.

    In qualità di utenti possiamo fare attenzione ai link che apriamo
    e alla presenza di anomalie. La disattivazione del supporto JavaScript
    o l'impostazione del livello Alto di protezione possono contrastare
    i codici nocivi ma creano problemi alla normale navigazione.

    Ricordiamo inoltre che le connessioni criptate tramite SSL (riconoscibili
    dall'url che inizia con https) non offrono una protezione
    aggiuntiva per queste falle.

    Ulteriori informazioni:

    HOWTO: Prevent Cross-Site Scripting Security Issues
    http://support.microsoft.com/default.aspx?scid=kb;en-us;252985&sd=tech
    Cross-site Scripting Overview
    http://www.microsoft.com/technet/security/news/csoverv.mspx
    Cross-Site Scripting: Frequently Asked Questions
    http://www.microsoft.com/technet/security/news/crsstfaq.mspx
    Quick Start: What Customers Can Do to Protect Themselves from Cross-Site
    Scripting
    http://www.microsoft.com/technet/security/news/crsstqs.mspx

    Hacker! 4.0 - Nuove tecniche di protezione, ed. Apogeo, pp. 612 - 613

Ti consigliamo anche