Qual è il concetto generale dietro XSS?

Lo scripting cross-site (XSS) è un tipo di vulnerabilità di sicurezza informatica tipicamente presente nelle applicazioni Web che consente agli aggressori malintenzionati di iniettare script lato client in pagine Web visualizzate da altri utenti. Una vulnerabilità di scripting cross-site sfruttata può essere utilizzata dagli aggressori per bypassare i controlli di accesso come la stessa politica di origine. Gli script cross-site eseguiti sui siti Web rappresentano all’incirca l’80% di tutte le vulnerabilità di sicurezza documentate da Symantec a partire dal 2007.

Ok, questo vuol dire che un hacker crea alcuni JS / VBscript dannosi e li consegna alla vittima ignara quando visita un sito legittimo che ha input senza escape?

Voglio dire, so come si fa l’iniezione SQL ….

In particolare, non capisco come JS / VBscript possa causare così tanti danni! I thoguht sono eseguiti solo all’interno dei browser, ma a quanto pare il danno varia da keylogging a cookie di furto e trojan .

La mia comprensione dell’XSS è corretta? se no, qualcuno può chiarire?

Come posso evitare che XSS si verifichi sui miei siti web? Questo sembra importante; L’80% delle vulnerabilità della sicurezza indica che si tratta di un metodo estremamente comune per compromettere i computer.

Straight Forward XSS

  1. Trovo che Google abbia una vulnerabilità xss
  2. Scrivo uno script che riscrive una pagina pubblica di Google per apparire esattamente come il vero login di Google
  3. La mia pagina falsa viene inoltrata a un server di terze parti e quindi reindirizza nuovamente alla pagina reale
  4. Ottengo le password dell’account google, gli utenti non si rendono conto di cosa è successo, Google non sa cosa sia successo

XSS come piattaforma per CSRF (questo apparentemente è accaduto realmente)

  1. Amazon ha una vulnerabilità csrf in cui un cookie “tienimi sempre connesso” ti consente di contrassegnare una voce come offensiva
  2. Trovo una vulnerabilità xss su un sito ad alto traffico
  3. Scrivo un javascript che richiama gli url per contrassegnare tutti i libri scritti da autori gay / lesbiche su Amazon come offensivi
  4. Per Amazon, stanno ricevendo richieste valide da veri browser con autentici cookie di autenticazione. Tutti i libri scompaiono dal sito durante la notte
  5. Internet va fuori di testa.

XSS come piattaforma per attacchi di Session Fixation

  1. Trovo un sito di e-commerce che non ripristina la loro sessione dopo un accesso (come qualsiasi sito asp.net), ha la capacità di passare l’id della sessione tramite la stringa di query o tramite cookie e memorizza le informazioni di autenticazione nella sessione (piuttosto comune )
  2. Trovo una vulnerabilità XSS su una pagina su quel sito
  3. Scrivo uno script che imposta l’ID di sessione su quello che controllo
  4. Qualcuno colpisce quella pagina, ed è imbattuto nella mia sessione.
  5. Si collegano
  6. Ora ho la possibilità di fare tutto ciò che voglio come loro, compreso l’acquisto di prodotti con tabs salvate

Quei tre sono i più grandi. Il problema con gli attacchi XSS, CSRF e Session Fixation è che sono molto, molto difficili da rintracciare e correggere e sono molto semplici da consentire, specialmente se uno sviluppatore non ne sa molto.

Poiché le risposte su come XSS può essere dannoso sono già state fornite, pubblicherò solo due belle presentazioni flash su XSS e risponderemo alla seguente domanda senza risposta:

come posso evitare che XSS si verifichi sui miei siti web?

Ecco due belle presentazioni flash su XSS:

Per quanto riguarda la prevenzione da XSS, è necessario eseguire l’escape HTML di qualsiasi input controllato dall’utente quando sta per essere nuovamente visualizzato sulla pagina. Ciò include intestazioni di richiesta, parametri di richiesta e qualsiasi input memorizzato controllato dall’utente che deve essere servito da un database. Soprattutto i < , > , " e ' devono essere sfuggiti, perché possono deformare il codice HTML circostante in cui questo input è stato nuovamente visualizzato.

Quasi tutte le tecnologie di visualizzazione forniscono metodi incorporati per sfuggire alle quadro HTML (o XML, che è anche sufficiente).

In PHP puoi farlo con htmlspecialchars() . Per esempio

  

Se è necessario sfuggire anche a singlequote con questo, sarà necessario fornire l'argomento ENT_QUOTES , vedere anche la documentazione PHP fornita a corredo.

In JSP puoi farlo con JSTL o fn:escapeXml() . Per esempio

 "> 

o

  

Si noti che in realtà non è necessario eseguire l'escape di XSS durante l'elaborazione della richiesta, ma solo durante l'elaborazione della risposta. L'escaping durante l'elaborazione della richiesta non è necessario e potrebbe prima o poi malformare l'input dell'utente (e come amministratore del sito vorresti anche sapere che cosa è effettivamente inserito dall'utente in modo da poter intraprendere azioni sociali se necessario). Per quanto riguarda le iniezioni SQL, è sufficiente sfuggire solo durante l'elaborazione delle richieste nel momento in cui i dati stanno per essere persistenti nel database.

Immagina un forum web. Un attacco XSS potrebbe essere che faccio un post con qualche javascript. Quando navighi sulla pagina, la tua pagina web caricherà ed eseguirà il js e farà ciò che dico. Come hai navigato alla pagina e molto probabilmente hai effettuato l’accesso, il mio javascript farà tutto ciò che hai i privilegi da fare, come fare un post, eliminare i tuoi messaggi, inserire spam, mostrare un popup, ecc.

Quindi il vero concetto con XSS è lo script eseguito nel contesto dell’utente, che è un’escalation di privilegi. È necessario fare attenzione che in qualsiasi punto dell’app che riceve l’input dell’utente sia ansible sfuggire qualsiasi script ecc. Al suo interno per garantire che non sia ansible eseguire un XSS.

Devi fare attenzione agli attacchi secondari. Immagina se inserissi script dannosi nel mio nome utente. Ciò potrebbe non essere controllato nel sito Web e quindi riscritto senza controllo, ma ogni pagina visualizzata con il mio nome utente potrebbe effettivamente eseguire script dannosi nel contesto dell’utente.

Esci dall’input dell’utente. Non eseguire il tuo codice per farlo. Controlla tutto ciò che sta succedendo e tutto ciò che viene fuori.

Non capisco come JS / VBscript possa causare così tanti danni!

Ok. supponiamo di avere un sito, e il sito è servito da http://trusted.server.com/thesite . Diciamo che questo sito ha una casella di ricerca e quando cerchi l’url diventa: http://trusted.server.com/thesite?query=somesearchstring .

Se il sito decide di non elaborare la stringa di ricerca e di visualizzarla nel risultato, ad esempio “Cerca” somesearchstring “non ha prodotto alcun risultato, quindi chiunque può inserire codice html arbitrario nel sito. Ad esempio:

 http://trusted.server.com/thesite?query=
username:
password:

Quindi, in questo caso, il sito mostrerà doverosamente un falso modulo di accesso nella pagina dei risultati di ricerca e, se l’utente lo invia, invierà i dati al malvagio server non attendibile. Ma l’utente non lo vede, esp. se l’url è molto lungo vedranno solo il primo ma, e assumeranno che si occupino di trusted.server.com.

Le varianti di questo includono l’iniezione di un tag che aggiunge i gestori di eventi al documento per tracciare le azioni dell'utente o inviare il cookie del documento al server malvagio. In questo modo puoi sperare di incontrare dati sensibili come dati di accesso, password o carta di credito. Oppure puoi provare ad inserire un appositamente disegnato che occupa l'intera finestra del client e serve un sito che assomiglia all'originale ma che in realtà proviene da evil.server.com. Finché l'utente è ingannato nell'usare il contenuto iniettato invece dell'originale, il compomesso della sicurezza.

Questo tipo di XSS è chiamato riflettente e non persistente. Riflettente perché l'url è "relected" direttamente nella risposta, e non persistente perché il sito reale non è cambiato - serve solo come passaggio. Si noti che qualcosa come https non offre alcuna protezione qui - il sito stesso è rotto, perché pappagge l'input dell'utente tramite la stringa di query.

Il trucco è ora di convincere gli utenti ignari a fidarsi di qualsiasi link che tu dai loro. Ad esempio, puoi inviare loro un'email in formato HTML e includere un link dall'aspetto attraente che rimanda all'URL contraffatto. Oppure puoi diffonderlo su wiki, forum, ecc. Sono sicuro che puoi apprezzare quanto sia facile - è solo un link, cosa potrebbe andare storto, giusto?

A volte può essere peggio. Alcuni siti memorizzano effettivamente contenuti forniti dagli utenti. Semplice esempio: commenti su un blog o discussioni su un forum. Oppure potrebbe essere più sottile: una pagina del profilo utente su un social network. Se quelle pagine consentono l'html arbitrario, esp. script, e questo html fornito dall'utente viene memorizzato e riprodotto, quindi tutti quelli che visitano semplicemente la pagina che contiene questo contenuto sono a rischio. Questo è XSS persistente. Ora gli utenti non hanno nemmeno bisogno di cliccare su un link, basta visitare è sufficiente. Anche in questo caso l'attacco effettivo consiste nel modificare la pagina attraverso lo script per acquisire i dati dell'utente.

L'inserimento di script può essere smussato, ad esempio, si può inserire uno completo oppure può essere sottile: .

Per quanto riguarda la protezione di te stesso: la chiave è non inviare mai l'input dell'utente. Questo può essere difficile se il tuo sito ruota attorno al contenuto fornito dall'utente con il markup.

I problemi degli attacchi XSS sono più legati alla pesca. Il problema è che un sito che un cliente si fida potrebbe essere iniettato con il codice che conduce al sito creato dall’attaccante per determinati scopi. Rubare informazioni sensibili, per esempio.

Quindi, negli attacchi XSS gli intrusi non entrano nel tuo database e non si scherzano con esso. Sta giocando con il senso nel cliente che questo sito è sicuro e ogni link su di esso punta a una posizione sicura.

Questo è solo il primo passo dell’attacco reale: portare il cliente nell’ambiente ostile.

Posso darti un breve esempio. Se un istituto bancario mette un shoutbox sulla loro pagina, per esempio e non mi impediscono di attaccare XSS, posso gridare “Ehi, vieni su questo link e inserisci le password e la carta di credito No per un controllo di sicurezza!” … E sai dove porterà questo link, giusto?

Puoi prevenire gli attacchi XSS assicurandoti di non visualizzare nulla sulla tua pagina, proveniente dall’input degli utenti senza sfuggire ai tag html. I caratteri speciali dovrebbero essere sfuggiti, in modo che non interferiscano con il markup delle tue pagine html (o con qualsiasi altra tecnologia tu usi). Ci sono molte librerie che forniscono questo, inclusa la libreria Microsoft AntiXSS.