RIA and Ajax Security Workshop – Web 2.0 Expo Berlin

A very interesting and informative talk dealing with the new types of attacks that affect web 2.0 applications and RIA in particular.

The session was divided in 2 parts, the first about AJAX and the last about Rich Internet Applications.

The slides of this talk are available on slideshare and are impressive for their completeness. Not only they provide detailed examples for every case illustrated, but they link to a series of articles and web resources.

The main problem of this talk is that it’s quite impossible to be able to be specific enough and, at the same time, don’t get too much into details. This resulted in some hard-to-understand parts.

AJAX

In general attacking an AJAX application is more difficult compared to a web 1.0 site. But on the other hand is more difficult to protect an AJAX application because there are more ways to exploit it and new ways are discovered every day.

  • Not all “web 2.0” sites use new technologies (such as Youtube and MySpace)
  • A single page in Myspace has a lots of includes.
  • Also Google Maps has a lot of includes, but ofJavascript code. Google code can be potentially insecure

Why care about web 2.0 security

  • People changed how they interact with web sites (they erase privacy barriers and they don’t feel the distance. The are the new generations)
  • Technologies spread from innovators to traditionalists (today AJAX in financial institutions, health care, government) – mainstream
  • Bugs are affecting people now

Discovery and method manipulation

  • Playing with parameters is still an excellent web attack (asking application to do the work for you). As business logic gets more complex, so do parameters vulnerabilities
  • Figuring out web apps is tough part of pen-test

Two types of Ajax apps

  • client-server proxy (equivalent to SOAP, client hides javascript)
  • client-side rendering (we can see the javascript and know what it does)

Cross Site Scripting

  • Downstream communication methods are much more complicated
  • User controlled data might be contained in arguments in dynamically created javascript, contained in Javascript arrays, etc. As a result, attack and defence is more difficult

Four bugs

  • downstream JS Arrays. Dangerous characters
  • XSS payload can be tucked into many places
  • XSS might already be in the dom (document.url, document.location, document.referer).
  • AJAX uses “backend” requests never expected to be seen directly in browser

RIA

Is ill-defined. Many contain many terms, AJAX, Flash, offline mode, decoupling from the browser. There is a huge disparity in features and security design.

Why use RIA

  • to increase responsiveness
  • desktop integration
  • to write full desktop apps

RIA Frameworks

No one framework is without limits and security problems. The worst seems Adobe Air because it shows all the limits of the very old ActiveX model.

The frameworks:

  • Adobe AIR
  • Microsoft Silverlight
  • Google Gears
  • Mozilla Prism

Adobe Air

  • Full-featured
  • Cross-browser, cross-platform
  • Created with Flex, Flash
  • Can be invoked by browser with arguments, like ActiveX or Flash
  • Air is best thought as ActiveX than Flash ++ (code runs with full privileges and can install malware)
  • SWF files can import functionalities that allows them to interact with AIR applications
  • SWF files can check install status and version
  • By default, code included in AIR application has full rights
  • There is not a “code access security” model such as in Java or .Net
  • AIR has many ways of loading executable content to run, such as HTML/JS and SWF
  • AIR applications can be bundled as binaries
  • Problems: allowing users to install signed applets is dangerous. Allowing self-signed is terrifying
  • Some suggestions to adobe: change default action, disable unsigned install prompts

Silverlight

Lot of sensibility toward security

  • Is the Microsoft Flash equivalent
  • Cross browser and cross platform
  • Subnet of the .NET frameworks
  • The security model is based on .NET
  • Calling system primitives the system will fail. You need to isolate it
  • What could go wrong (threading, DoS attacks against local system)

Google Gears

  • Has SQLite embedded
  • Uses an homegrown API for synchronizing data
  • Has a LocalServer
  • Works offline via SQL database, local assets and a local app server
  • Uses some origin to restrict access to site databases and LocalServer resource capture
  • Provides for parametrized SQL
  • Unfortunately they allows personalization of opt-in screen

Yahoo! Browserplus

  • A very bad idea
  • Runs as a browser plugin, with a separate helper process
  • It’s very similar to ActiveX concepts
  • Use old version or Ruby. Perfectly safe as long as you don’t use strings and arrays

Mozilla Prism

  • Wraps webapps to appears as desktop apps
  • Standalone browser instance
  • Problem: the Javascript included with webapps has full XPCOM privileges (but no content scripting privileges)
  • Problem: the sandbox isn’t real

HTML 5

HTML introduces some new concepts related to storage of informations.

  • Introduces DOM storage (sessionStorage, localStorage, database storage)
  • The major goals are more storage space and real persistence, because cookies are considered too small and users delete cookies or won’t accept them
  • This method bypasses pesky users, that however can use a specific about:config directive

Browser based SQL Databases

  • Injection becomes far more damaging (because of lot of privileges)

Checklist

  • prevent predictability named data stores
  • parametrize sql statements

Summary

  • RIA frameworks widely vary in their security models
  • It is highly likely that web developers will introduce interesting flaws into their desktop applications
Alex Stamos is a Founding Partner of iSEC Partners, Inc, a strategic digital security organization. Alex is an experienced security engineer and consultant specializing in application security and securing large infrastructures, and has taught multiple classes in network and application security. He is a leading researcher in the field of web application and web services security and has been a featured speaker at top industry conferences such as Black Hat, CanSecWest, DefCon, SyScan, Microsoft BlueHat and OWASP App Sec. He is a contributing author of “Hacking Exposed: Web 2.0” and holds a BSEE from the University of California, Berkeley.

Dave Morin (Facebook) – The story behind the facebook platform

Morin ha passato i primi minuti a presentare Facebook (ehi, io sono iscritto: se ci conosciamo, aggiungimi).

Facebook è una “techonogy company”. Hanno 43 millioni di utenti, 225.000 nuovi iscritti al giorno, 3% d nuovi ogni settimana, il doppio ogni 6 mesi, più del 50% fuori dagli USA.; oltre il 50% torna ogni giorno sul sito. Facebook è una piattaforma aperta: grazie agli standard API resi disponibili da Facebook, sviluppatori di terze parti possono proporre l’aggiunta di applicazioni che ne estendono le potenzialità.

Divide la piattaforma in 3 caratteristiche.

Deep integration (integrazione)

Se guardiamo le applicazioni che compongono Facebbok, come ad esempio quella per le foto, notiamo che come concezione sono molto semplici, e le funzionalità non troppo complesse. Eppure Facebook fa più traffico con le proprie applicazione scritte in poco tempo, piuttosto che quelle dedicate (come Flickr di Yahoo! per esempio). Il motivo, secondo Morin, è che sono integrate nel profilo dell’utente Facebook, quindi facilmente accessibili, con possibilità per gli altri di commentare e integrare facilmente.

Mass distribution (distribuzione di massa)

Quando un utente aggiunge una nuova applicazione, gli altri nel network hanno la possibilità di vedere che l’utente l’ha aggiunta. Se vogliono partecipare, commentare, integrare o vedere quello che sta facendo il loro amico, sono invitati ad aggiungere loro stessi l’applicazione, cosa che è super-facile.

Opportunity (opportunità)

Il modello di creazione di un’applicazione può essere sintetizzato in 3 elementi: crescita, interesse, guadagno. La piattaforma di Facbook cerca di ridurre i tempi della crescita grazie alla distribuzione di massa: più dell’80% degli utenti Facebook hanno aggiunto almeno un’applicazione.Facebook sta anche cominciando un percorso per pagare interessanti applicazioni sviluppate da terze parto.

Oggi ci sono più di 5000 applicazioni per facebook e più di 90.000 sviluppatori checi lavorano.

Questo intervento è stato scritto in live blogging dalla conferenza Future of Web Apps di Londra, il 3 e 4 Ottobre 2007. Leggi tutti gli interventi di Fucinaweb dal FOWA

Ha senso imparare Ajax?

Che in futuro la percentuale di applicazioni web di tipo Ajax (e Ria in generale) aumenti sempre più è un dato di fatto. Ma non è ancora chiaro chi, all’interno del team di sviluppo di un progetto web, debba imparare a masticare questa nuova architettura. Tutti? Solo chi si preoccupa della programmazione? Chi sviluppa i template? Il designer?

Chi progetta l’interfaccia

Uso qui impropriamente il termine “progettare l’interfaccia” intendendo in realtà molte specifiche professionalità, illustrate sapientemente da Jesse James Garrett nel diagramma “The Elements of User Experience“.

Chi rientra in questa categoria farebbe bene a capire come per l’utente cambia il modo di usare un sito che utilizzi Ajax. Perché le possibilità aumentano e l’interattività si avvicina a quella di un normale programma per computer. Per capire cosa intendo potete dare un’occhiata a quanto messo a disposizione da Yahoo!. Ma tutto questo pone anche dei problemi per quanto riguarda l’accessibilità e l’usabilità di Ajax.

Chi declina il template

La cosa più importante che deve fare chi si occupa del lavoro sporco, ovvero di convertire i template in codice Html e fogli di stile, è fare in modo che questi aderiscano il più possibile agli standard web. Non solo sulla carta, ma per davvero, come dico da due anni e passa.

Il fatto che Ajax impieghi massicciamente Javascript, realizzato solitamente da chi si occupa di produrre l’Html della pagina, potrebbe trarre in inganno. Si tratta infatti di un uso avanzato di Javascript, da lasciare a chi lavora lato server.

Chi scrive il codice lato server

Ecco, direte, quali sono i veri utilizzatori di Ajax, le persone che si infangano le mani tra codice Javascript e programmazione lato server…o no?

Certo, per capire come funziona Ajax suggerisco di creare da zero un piccolo esempio, ma è imprensabile sviluppare applicazioni complesse in questo modo.

Molto meglio votarsi a un framework che sollevi da questa responsabilità. Ma se possibile non un framework lato client, come ad esempio Prototype.

In futuro (neanche tanto lontano, basti pensare a quello che sta facendo, tra gli altri, Microsoft con Atlas), il supporto per Ajax sarà integrato direttamente all’interno dei framework di sviluppo lato server, tanto da renderne “invisibile” il funzionamento.

Attenzione però, perché trasparente fa rima con pericoloso. Dovrete prestare comunque attenzione a quello che fate; non dimenticatevi che siete sempre alle prese con un browser e – la maggior parte delle volte – con il protocollo Http.