HTML5 Security
2 likes1,921 views
Il documento tratta le problematiche di sicurezza associate all'HTML5, evidenziando che la sicurezza si sposta principalmente dal server al client. Vengono analizzati vari tipi di attacchi, come XSS, CSRF e clickjacking, e si suggeriscono pratiche di codifica sicura, come la validazione dei dati e l'uso di tecniche come il sandboxing. Infine, si raccomanda l'implementazione di header HTTP di sicurezza per proteggere gli utenti da potenziali minacce.
![il
WebStorage
è
potenzialmente
vulnerabile
alle
SQL
InjecBon,
usare
le
prepared
statement
db.executeSql('SELECT
name FROM names WHERE
id=?',[name]);](https://image.slidesharecdn.com/html5securityxssclickjackingabusewebstoragewebsqlsandboxcors-130322110559-phpapp02/85/HTML5-Security-27-320.jpg)
HTML5 Security
- 1. Simone Onofri Hackers vs Developers - HTML5 Security simone.onofri@techub.it - Techub S.p.A.
- 2. Introduzione
- 5. Introduzione
- 6. cosa cambia con l’HTML5 in ambito Security?
- 7. Quali sono gli a=acchi e le minacce? Events Tag & ACributes Thick Features Abuso di funzioni (es. Drag ‘n Drop, Geloca;on) Web Workers Abusi su Widget Botnet/Spyware XSS / Redirect esterni e Mashup Furto di Informazioni ClickJacking Parser/Threads DOM Storage/Database Inserimento di informazioni UI Redressing malevole/DoS per gli uten; XHR WebSocket Plug-‐in Sockets Abuso della rete del client tramite API e Socket (es. Ddos, Browser Na;ve Network Services interceCazione, scansioni) Sandbox Same Origin Policy Abusi e CSRF
- 8. A=acchi più o meno Bpici su HTML5 La sicurezza si sposta lato client, il bene principalmente a3accato è l’utente con il suo disposi7vo.
- 9. Cross Site ScripBng (XSS)
- 10. Cross Site Request Forgery (CSRF) s ou a lici gia ta m for sito est a al chi ita r i vis la on a c gin pa esecuzione della richiesta forgiata conferma dell’esecuzione
- 11. Click Jacking/UI Redressing evil.com user: pass:
- 12. Abusi su funzionalità di interazione
- 13. Abusi di risorse degli utenB/InformaBon Leak
- 15. 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.
- 16. nuovi elemenB = nuovi punB di a=acco
- 17. eventuali blacklist vanno aggiornate (un moBvo in più per non usarle)
- 19. <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...
- 20. <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
- 21. 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”.
- 22. l’accesso è regolato dalla triple=a protocollo-‐dominio-‐porta...
- 23. ...ma non dal path!
- 24. uBlizzare il sessionStorage per i daB temporanei
- 25. i daB sono manipolabili, quindi considerarli sempre come “non affidabili”
- 26. non memorizzare daB sensibili, come token di sessione
- 27. il WebStorage è potenzialmente vulnerabile alle SQL InjecBon, usare le prepared statement db.executeSql('SELECT name FROM names WHERE id=?',[name]);
- 28. a=enzione ai Cross Site ScripBng
- 29. Web Messaging Funzionalità di HTML5 che perme3ere di trasme3ere informazioni tra documenB di origine differente (es. domini) per esempio a3raverso iframe differen7.
- 30. quando si invia un messaggio, indicare esplicitamente l’origine che ci aspe`amo. es. evitare window.postMessage("Test" , "*")
- 31. quando riceviamo i daB a=enzione ai Cross Site ScripBng!
- 32. es. al posto di usare element.innerHTML uBlizzare element.textContent
- 33. verificare sempre, in maniera efficace, l’origine della richiesta!
- 34. es. evitare controlli come message.orgin.indexOf(".e xample.org")!=-1
- 35. 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.
- 36. evitare vecchi protocolli insicuri come hixie-75 o hixie-76/ hybi-00. UBlizzare l’RFC-6455
- 37. a=enzione ai Cross Site ScripBng
- 38. non è un protocollo che gesBsce l’autenBcazione o l’autorizzazione: va gesBta lato applicaBvo
- 39. i daB sensibili non devono passare in chiaro (ws://) ma essere cifraB (wss://)
- 40. verificare sempre gli input e gli output
- 42. 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.
- 43. verificare sempre le richieste passate da XHR
- 44. Access-Control-Allow- Origin: * solo per URL che non espongono informazioni sensibili
- 45. uBlizzare il principio del privilegio minimo: blacklist su tu=o e whitelist dei soli domini permessi
- 46. a=enzione all’uBlizzo di Access-Control-Allow- Credentials: true e non rifle=erlo mai
- 47. a=enzione alla cache, uBlizzaere l’header Access-Control-Max-Age
- 48. considerare che il tu=o può essere bypassato con un HTTP Response spli`ng
- 49. L’Origin può essere alterato, per cui non fare affidamento solo su quello
- 50. 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.
- 51. uBlizzare l’a=ributo sandbox negli iframe che possono contere contento sul quale non abbiamo controllo
- 52. è possibile abilitare un controllo granulare su form, pop-‐up, same-‐ origin, script e gesBone del puntatore
- 53. 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).
- 54. validare sempre i daB, sia per evitare che sia possibile inserire codice malevolo nel worker...
- 55. ...sia per evitare DOM XSS (es. non usare eval() nei parametri passaB)
- 56. 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.
- 57. anche se l’RFC prevede la conferma lato UA, prevedere comunque un interazione prima dell’invio dei daB
- 58. 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.
- 59. X-Content-Type-Options: nosniff per forzare il mime-‐type specificato ed evitare XSS
- 60. X-XSS-Protection: 1; mode=block per abilitare le protezioni anB-‐XSS del browser
- 61. X-Frame-Options: deny per evitare il ClickJacking/UI Redressing
- 62. Strict-Transport- Security: max-age=60000; includeSubDomains per evitare problemaBche nel livello di trasporto
- 63. Content-Security-Policy/ X-WebKit-CSP/X-Content- Security-Policy per evitare XSS, ClickJacking/UI Redressing, MiTM
- 64. Conclusioni