hackers vs. developers: html5 security by simone onofri

Post on 25-May-2015

528 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

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

simone.onofri@techub.it - Techub S.p.A.

Simone Onofri

Hackers vs Developers - HTML5 Security

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

top related