• Like
  • Save
HTML5 Security
Upcoming SlideShare
Loading in...5
×
 

HTML5 Security

on

  • 1,216 views

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 ...

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.

Statistics

Views

Total Views
1,216
Views on SlideShare
1,198
Embed Views
18

Actions

Likes
1
Downloads
0
Comments
0

3 Embeds 18

https://twitter.com 9
http://www.linkedin.com 8
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    HTML5 Security HTML5 Security Presentation Transcript

    • Simone OnofriHackers vs Developers - HTML5 Securitysimone.onofri@techub.it - Techub S.p.A.
    • 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  &  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
    • A=acchi  più  o  meno  Bpici  su  HTML5La  sicurezza  si  sposta  lato  client,  il  bene  principalmente  a3accato  è  l’utente  con  il  suo  disposi7vo.
    • Cross  Site  ScripBng  (XSS)
    • 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
    • Click  Jacking/UI  Redressing evil.com user: pass:
    • Abusi  su  funzionalità  di  interazione
    • Abusi  di  risorse  degli  utenB/InformaBon  Leak
    • Cosa  bisogna  fare
    • 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.  
    • 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  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”.
    • 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  MessagingFunzionalità  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  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.
    • 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  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.
    • 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
    • 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.
    • uBlizzare  l’a=ributo  sandboxnegli  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  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).
    • 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  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.  
    • anche  se  l’RFC  prevede  la  conferma   lato  UA,  prevedere  comunque  un  interazione  prima  dell’invio  dei  daB
    • 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.
    • 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
    • ;-­‐)http://onofri.org/http://twitter.com/simoneonofrihttp://it.linkedin.com/simoneonofrihttp://slideshare.net/simoneonofriGRAZIE!
    • http://onofri.org/http://twitter.com/simoneonofrihttp://it.linkedin.com/simoneonofrihttp://slideshare.net/simoneonofriDOMANDE ?