hackers vs. developers: html5 security by simone onofri
DESCRIPTION
HTML5 è lo standard futuro per lo sviluppo di applicazioni web e mobile che aggiunge molte funzionalità e potenzialità rispetto l’(X)HTML tradizionale. Se per gli sviluppatori sono aumentate le possibilità, In ambito Security aumenta la superficie attaccabile in particolare per gli attacchi lato client. Il talk si pone l’obiettivo di descrivere i nuovi vettori di attacco che insistono sulle API e funzionalità di HTML5.TRANSCRIPT
Introduzione
h"p://onofri.org/u/html5sec
Introduzione
cosa cambia con l’HTML5 in ambito Security?
Quali sono gli a=acchi e le minacce?
Events Tag & A"ributes Thick Features
DOMParser/Threads
XHR WebSocket Plug-‐in Sockets
Browser Na@ve Network Services
Same Origin PolicySandbox
Storage/Database
XSS / Redirect
Furto di InformazioniInserimento di informazioni malevole/DoS per gli uten@
Abuso della rete del clienttramite API e Socket (es. Ddos, interce"azione, scansioni)
Abusi e CSRF
ClickJackingUI Redressing
Web WorkersBotnet/Spyware
Abusi su Widget esterni e Mashup
Abuso di funzioni (es. Drag ‘n Drop, Geloca@on)
A=acchi più o meno Bpici su HTML5
La sicurezza si sposta lato client, il bene principalmente a3accato è l’utente con il suo disposi7vo.
Cross Site ScripBng (XSS)
Cross Site Request Forgery (CSRF)
visita a
l sito m
aliciou
s
pagina
con la r
ichiesta
forgiat
a
esecuzione della richiesta forgiata
conferma dell’esecuzione
Click Jacking/UI Redressing
evil.comuser:pass:
Abusi su funzionalità di interazione
Abusi di risorse degli utenB/InformaBon Leak
Cosa bisogna fare
Tags & A=ributes / DOM
Su Tag, A3ribu7 e nel DOM insiste una delle vulnerabilità più note della sicurezza delle applicazioni web: il Cross Site ScripBng. HTML5, proponendo nuovi elemen7 e a3ribu7 -‐ aumenta la superficie a3accabile. I rischi connessi sono molteplici e sono alla base di mol7 scenari di abuso o ulteriori problema7che di sicurezza.
nuovi elemenB = nuovi punB di a=acco
eventuali blacklist vanno aggiornate (un moBvo in più per non usarle)
verificare e codificare!
<form id="test"></form><button form="test" formaction="javascript:alert(1)">X</button>
<input onfocus=write(1) autofocus>
<input onblur=write(1) autofocus><input autofocus>
<video poster=javascript:alert(1)/></video>
<body onscroll=alert(1)><br><br><br><br><br><br>...<br><br><br><br><input autofocus>
<form id=test onforminput=alert(1)><input></form><button form=test onformchange=alert(2)>X</button>
<video><source onerror="alert(1)">
<video onerror="alert(1)"><source></source></video>
<form><button formaction="javascript:alert(1)">X</button>
Nuovi ve3ori XSS...
<body oninput=alert(1)><input autofocus>
<math href="javascript:alert(1)">CLICKME</math>
<input name="injected" value="injected" dirname="password" />
0?<script>Worker("#").onmessage=function(_)eval(_.data)</script>
:postMessage(importScripts('data:;base64,cG9zdE1lc3NhZ2UoJ2FsZXJ0KDEpJyk'))
<script>crypto.generateCRMFRequest('CN=0',0,0,null,'alert(1)',384,null,'rsa-dual-use')</script>
...e altri ve3ori XSS
Storage e Client-‐side Database
Storage locali, di sessione o i Client-‐side Database possono mantenere svariate quan7tà di da7. E’ possibile rubare, cancellare manipolare i daB, es. tramite un Cross Site Scrip7ng o semplicemente accedendo localmente al browser. I da7 devono quindi essere sempre validaB e non uBlizzaB per scelte di “sicurezza”.
l’accesso è regolato dalla triple=a protocollo-‐dominio-‐porta...
...ma non dal path!
uBlizzare il sessionStorage per i daB temporanei
i daB sono manipolabili, quindi considerarli sempre come “non
affidabili”
non memorizzare daB sensibili, come token di sessione
il WebStorage è potenzialmente vulnerabile alle SQL InjecBon, usare
le prepared statement db.executeSql('SELECT name FROM names WHERE
id=?',[name]);
a=enzione ai Cross Site ScripBng
Web Messaging
Funzionalità di HTML5 che perme3ere di trasme3ere informazioni tra documenB di origine differente (es. domini) per esempio a3raverso iframe differen7.
quando si invia un messaggio, indicare esplicitamente l’origine che
ci aspe`amo. es. evitare window.postMessage("Test"
, "*")
quando riceviamo i daB a=enzione ai Cross Site ScripBng!
es. al posto di usare element.innerHTML uBlizzare
element.textContent
verificare sempre, in maniera efficace, l’origine della richiesta!
es. evitare controlli come message.orgin.indexOf(".e
xample.org")!=-1
Web Sockets
Protocollo introdo3o in HTML5, perme3e una comunicazione full-‐duplex all’interno di una connessione TCP. Il collegamento con HTTP si limita all’handshake. A3enzione: alcuni proxy potrebbero non gradire il 426 Upgrade Required.
evitare vecchi protocolli insicuri come hixie-75 o hixie-76/hybi-00. UBlizzare l’RFC-6455
a=enzione ai Cross Site ScripBng
non è un protocollo che gesBsce l’autenBcazione o l’autorizzazione:
va gesBta lato applicaBvo
i daB sensibili non devono passare in chiaro (ws://) ma essere cifraB
(wss://)
verificare sempre gli input e gli output
verificare sempre l’Origin
Cross Origin Resource Sharing
Perme3e di bypassare la Same Origin Policy -‐ senza usare workaround come JSONP e comunicare con URL esterni. Questo vale anche per l’XMLH3pRequest, la policy si concre7zza in alcuni header HTTP che vanno u7lizza7 in maniera opportuna per evitare che i propri ogge` siano richiama7 da fon7 esterne e u7lizzare l’Origin come potenziale protezione di Cross Site Request Forgery.
verificare sempre le richieste passate da XHR
Access-Control-Allow-Origin: * solo per URL che non espongono informazioni sensibili
uBlizzare il principio del privilegio minimo: blacklist su tu=o e whitelist
dei soli domini permessi
a=enzione all’uBlizzo di Access-Control-Allow-Credentials: true e non
rifle=erlo mai
a=enzione alla cache, uBlizzaere l’header
Access-Control-Max-Age
considerare che il tu=o può essere bypassato con un HTTP Response
spli`ng
L’Origin può essere alterato, per cui non fare affidamento solo su
quello
Sandboxing
U7lizzare il sandboxing per ges7re iframe con contenu7 dove non abbiamo controllo per o3eniamo così una sandbox rispe3o l’origin, form e script disabilita7, i link non possono uscire dal contesto, trigger automa7ci disabilita7, plugin disabilita7, così da isolare eventuali Widget o Mashup malevoli e mi7gare il Clickjacking/UI Redressing.
uBlizzare l’a=ributo sandbox negli iframe che possono contere contento sul quale non abbiamo
controllo
è possibile abilitare un controllo granulare su form, pop-‐up, same-‐
origin, script e gesBone del puntatore
Web Workers
Nuova funzionalità di HTML5, perme3e di eseguire porzioni di codice Javascript in maniera asincrona, al ne3o del codice visualizzato. Anche se non hanno accesso al DOM possono comunque eseguire richieste XHR ed essere abusaB sfru=ando eccessivamente la CPU per eseguire operazioni di calcolo distribuito (es. password cracking) oppure DoS verso l’utente mobile (es. consumando velocemente la ba3eria).
validare sempre i daB, sia per evitare che sia possibile inserire codice malevolo nel worker...
...sia per evitare DOM XSS (es. non usare eval() nei parametri
passaB)
Thick Features
Funzionalità di HTML5 che perme3ono di integrarsi con il disposi7vo u7lizzato dall’utente come la Goloca7on API e File API. Le problema7che possono essere l’abuso della funzionalità -‐ anche tramite ClickJacking/UI Redressing, CSRF o XSS -‐ per so=rarre informazioni/file agli utenB.
anche se l’RFC prevede la conferma lato UA, prevedere comunque un interazione prima dell’invio dei daB
HTTP Header ProtecBon
Se le minacce sono sul client, le protezioni sono negli HTTP Header. I vari vendor hanno proposto svaria7 header di protezione che si sono man mano diffusi. Sono disponibili header come protezione accessoria contro i Cross Site ScripBng, Clickjacking/UI Redressing e problemaBche nel livello di trasporto.
X-Content-Type-Options: nosniff per forzare il mime-‐type
specificato ed evitare XSS
X-XSS-Protection: 1; mode=block per abilitare le protezioni anB-‐XSS del browser
X-Frame-Options: deny per evitare il ClickJacking/UI Redressing
Strict-Transport-Security: max-age=60000; includeSubDomains per evitare
problemaBche nel livello di trasporto
Content-Security-Policy/X-WebKit-CSP/X-Content-Security-Policy per evitare XSS, ClickJacking/UI Redressing,
MiTM
Conclusioni
GRAZIE!
;-‐)http://onofri.org/http://twitter.com/simoneonofrihttp://it.linkedin.com/simoneonofrihttp://slideshare.net/simoneonofri
DOMANDE
?http://onofri.org/http://twitter.com/simoneonofrihttp://it.linkedin.com/simoneonofrihttp://slideshare.net/simoneonofri