HTML5 Security

1,282
-1

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,282
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

HTML5 Security

  1. 1. Simone OnofriHackers vs Developers - HTML5 Securitysimone.onofri@techub.it - Techub S.p.A.
  2. 2. Introduzione
  3. 3. h"p://onofri.org/u/html5sec
  4. 4. Introduzione
  5. 5. cosa  cambia  con  l’HTML5  in  ambito   Security?
  6. 6. 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
  7. 7. A=acchi  più  o  meno  Bpici  su  HTML5La  sicurezza  si  sposta  lato  client,  il  bene  principalmente  a3accato  è  l’utente  con  il  suo  disposi7vo.
  8. 8. Cross  Site  ScripBng  (XSS)
  9. 9. 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
  10. 10. Click  Jacking/UI  Redressing evil.com user: pass:
  11. 11. Abusi  su  funzionalità  di  interazione
  12. 12. Abusi  di  risorse  degli  utenB/InformaBon  Leak
  13. 13. Cosa  bisogna  fare
  14. 14. Tags  &  A=ributes  /  DOMSu  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.  
  15. 15. nuovi  elemenB  =  nuovi  punB  di   a=acco
  16. 16. eventuali  blacklist  vanno  aggiornate   (un  moBvo  in  più  per  non  usarle)
  17. 17. verificare  e  codificare!
  18. 18. <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...
  19. 19. <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
  20. 20. Storage  e  Client-­‐side  DatabaseStorage  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”.
  21. 21. l’accesso  è  regolato  dalla  triple=a   protocollo-­‐dominio-­‐porta...
  22. 22. ...ma  non  dal  path!
  23. 23. uBlizzare  il  sessionStorage  per   i  daB  temporanei
  24. 24. i  daB  sono  manipolabili,  quindi  considerarli  sempre  come  “non   affidabili”
  25. 25. non  memorizzare  daB  sensibili,   come  token  di  sessione
  26. 26. il  WebStorage  è  potenzialmente  vulnerabile  alle  SQL  InjecBon,  usare   le  prepared  statement db.executeSql(SELECT name FROM names WHERE id=?,[name]);
  27. 27. a=enzione  ai  Cross  Site  ScripBng
  28. 28. Web  MessagingFunzionalità  di  HTML5  che  perme3ere  di  trasme3ere  informazioni  tra  documenB  di  origine  differente  (es.  domini)  per  esempio  a3raverso  iframe  differen7.
  29. 29. quando  si  invia  un  messaggio,  indicare  esplicitamente  l’origine  che   ci  aspe`amo.  es.  evitare  window.postMessage("Test" , "*")
  30. 30. quando  riceviamo  i  daB  a=enzione   ai  Cross  Site  ScripBng!
  31. 31. es.  al  posto  di  usare  element.innerHTML uBlizzare   element.textContent
  32. 32. verificare  sempre,  in  maniera  efficace,  l’origine  della  richiesta!
  33. 33.  es.  evitare  controlli  come  message.orgin.indexOf(".e xample.org")!=-1
  34. 34. Web  SocketsProtocollo  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.
  35. 35. evitare  vecchi  protocolli  insicuri  come  hixie-75  o  hixie-76/hybi-00.  UBlizzare  l’RFC-6455
  36. 36. a=enzione  ai  Cross  Site  ScripBng
  37. 37. non  è  un  protocollo  che  gesBsce  l’autenBcazione  o  l’autorizzazione:   va  gesBta  lato  applicaBvo
  38. 38. i  daB  sensibili  non  devono  passare  in  chiaro  (ws://)  ma  essere  cifraB   (wss://)
  39. 39. verificare  sempre  gli  input  e  gli   output
  40. 40. verificare  sempre  l’Origin
  41. 41. Cross  Origin  Resource  SharingPerme3e  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.
  42. 42. verificare  sempre  le  richieste   passate  da  XHR
  43. 43. Access-Control-Allow-Origin: * solo  per  URL  che  non   espongono  informazioni  sensibili
  44. 44. uBlizzare  il  principio  del  privilegio  minimo:  blacklist  su  tu=o  e  whitelist   dei  soli  domini  permessi
  45. 45. a=enzione  all’uBlizzo  di  Access-Control-Allow-Credentials: true e  non   rifle=erlo  mai
  46. 46. a=enzione  alla  cache,  uBlizzaere   l’header  Access-Control-Max-Age
  47. 47. considerare  che  il  tu=o  può  essere   bypassato  con  un  HTTP  Response   spli`ng
  48. 48. L’Origin può  essere  alterato,  per   cui  non  fare  affidamento  solo  su   quello
  49. 49. SandboxingU7lizzare  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.
  50. 50. uBlizzare  l’a=ributo  sandboxnegli  iframe  che  possono  contere   contento  sul  quale  non  abbiamo   controllo
  51. 51. è  possibile  abilitare  un  controllo  granulare  su  form,  pop-­‐up,  same-­‐ origin,  script  e  gesBone  del   puntatore
  52. 52. Web  WorkersNuova  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).
  53. 53. validare  sempre  i  daB,  sia  per  evitare  che  sia  possibile  inserire   codice  malevolo  nel  worker...
  54. 54. ...sia  per  evitare  DOM  XSS  (es.  non   usare  eval()  nei  parametri   passaB)
  55. 55. Thick  FeaturesFunzionalità  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.  
  56. 56. anche  se  l’RFC  prevede  la  conferma   lato  UA,  prevedere  comunque  un  interazione  prima  dell’invio  dei  daB
  57. 57. HTTP  Header  ProtecBonSe  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.
  58. 58. X-Content-Type-Options:nosniff per  forzare  il  mime-­‐type   specificato  ed  evitare    XSS
  59. 59. X-XSS-Protection: 1; mode=block  per  abilitare  le  protezioni  anB-­‐XSS  del  browser
  60. 60. X-Frame-Options: deny  per  evitare  il  ClickJacking/UI  Redressing
  61. 61. Strict-Transport-Security: max-age=60000;includeSubDomains  per  evitare   problemaBche  nel  livello  di   trasporto
  62. 62. Content-Security-Policy/X-WebKit-CSP/X-Content-Security-Policy  per  evitare   XSS,  ClickJacking/UI  Redressing,   MiTM
  63. 63. Conclusioni
  64. 64. ;-­‐)http://onofri.org/http://twitter.com/simoneonofrihttp://it.linkedin.com/simoneonofrihttp://slideshare.net/simoneonofriGRAZIE!
  65. 65. http://onofri.org/http://twitter.com/simoneonofrihttp://it.linkedin.com/simoneonofrihttp://slideshare.net/simoneonofriDOMANDE ?

×