Ajax è davvero una bella tecnologia. La capacità  di riportare le interazioni fra web server e l’interfaccia in modalità  asincrona conferisce più fluidità  di utilizzo e una migliore, come si dice, “user experience”. Ma, nel campo delle applicazioni software, aggiungendo complessità  spesso si aggiunge anche minor controllo.

Un tale Samy, qualche giorno fa, ha “bucato” Myspace.com, una delle più grandi comunità  di relazioni sul Web, utilizzando le potenzialità  di Ajax. Il giovane, che ha 19 anni e si definisce un “playboy/software developer”, ha semplicemente aggiunto al proprio profilo del codice JavaScript che non solo, anche grazie alla complicità  del browser, ha eluso i diversi controlli dell’applicazione Web, ma è riuscito a rendersi praticamente invisibile all’esecuzione utilizzando l’oggetto XMLHTTPRequest.

Ogni utente che visualizzava il profilo di Samy aggiungeva, automaticamente, lo stesso Samy al suo elenco di amici. Se nel profilo dell’utente “aggredito” era previsto anche l’elenco di “heroes”, Samy si aggiungeva anche a quello con la frase “but most of all, samy is my hero”. Non finisce qui: il codice venica incluso nel profilo dell’utente aggredito, propagandosi esponenzialmente. In meno di 24 ore Samy aveva oltre un milione di nuovi amici ed un nuovo business.

L’aggiunta e la modifica del profilo solitamente richiedono l’intervento dell’utente. Per rendere i vari GET e POST silenziosi, il nostro Samy ha utilizzato un tipico oggetto Ajax (XMLHTTPRequest) che, lavorando in sottofondo, eseguiva tutte le procedure all’insaputa del navigatore.

Sfruttare una simile vulnerabilità  non in remote scripting, ma con i normali linguaggi lato server asincroni (sì, i vecchi Click-and-Wait), sarebbe stato più complesso e più visibile, ma ugualmente fattibile. Tuttavia il principio generale di minor controllo dell’utente sui dati inviati, proprio di Ajax, vale in generale ed è ben descritto da un articolo su Devx.com:

Oggi, la profilazione serve ai gestori di siti per individuare tendenze, visualizzare le abitudini di navigazione o problemi di usabilità . Fino ad oggi gli sviluppatori potevano solo analizzare dati (“posted data”) che gli utenti decidono di inviare. [...] Con Ajax le azioni degli utenti possono essere costantemente monitorate. Tutto cià che può essere fatto, viene effettivamente fatto [...]. Pensate, per esempio, se un giorno il vostro iPod cade e smette di funzionare. Sperando nella sostituzione in garanzia, scrivete una mail al supporto Apple che recita: “Ho comprato da poco un iPod. L’ho fatto cadere per le scale. Ora ha smesso di funzionare”. Per evitare problemi, potete decidere di cancellare il secondo periodo. TROPPO TARDI! Se il sito utilizza Ajax, la tua richiesta potrebbe essere già  stata inviata.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS
10 CommentiDi' la tua

Il tuo indirizzo email non sarà mostrato pubblicamente. I campi obbligatori sono contrassegnati da *

Dal titolo del post, dal fatto che e' catalogato sulla voce sicurezza, dal fatto che si associa ajax ad un potenziale minor controllo, dal fatto che il bug report per me fa solo scoprire, passo passo, come per magia, quanto abbiano cannato lato server, ho interpretato male il tuo messaggio. Il mio intervento era in generale per sfatare il mito ajax = minor controllo o ajax = più vulnerabilità  ... semplicemente Skid X ha racchiuso in 3 righe il mio pensiero e se era anche il tuo, cosa abbiamo postato a fare 9 volte ? :D Saluti, e fate sempre i controlli lato server :P P.S. occhio che anche qui avete i tag abilitati :D

andr3a
andr3a

Sottoscrivo Skid X, é quello che avevo in mente scrivendo il post. Il mio dito, Andrea, non indicava Ajax, ma l'uso che di Ajax (XMLHTTPRequest) é stato fatto per sfruttare il bug. Non incolpo Ajax (figurati!), ma é interessante riflettere, in termini di sicurezza, sull'utilizzo che ne é stato fatto per rendere più fluido l'attacco. Ma per questo ci sarà  tempo: con l'aumento di notorietà , con l'esponenziale documentazione e disponibilità  di script pronti all'uso ne sentiremo delle belle ;) Saluti, Francesco (Cassandra).

Francesco
Francesco

La nuova tecnologia può rendere complicato all'utente di accorgersi del traffico client/server, ma i controlli lato server prescindono dal modo in cui il client fa le richieste. Il "bug" é solo lì, ed esiste da sempre, non é una novità  di Ajax.

Skid X
Skid X

>> penso agli svilupatori, quelli che hanno cannato. vorrei evitare polemiche su questa frase, tutti possono cannare, é normalissimo e sprattutto frequente su sistemi complessi. Almeno la decenza di dire "sono stato un fagiano", invece di dire "ho fatto tutto bene", é colpa di ajax e del browser... suvvia, siamo un pò più realisti, se comprassi un tavolo senza trattamento per l' unidità  e me lo ritrovassi con gli zampi ondulati non direi é colpa dell' umidità  ... o no ? ( marò che esempio brutto ... va beh, giorno ... )

andr3a
andr3a

>> Guardiamo sempre al dito infatti accusare ajax e' guardare il dito >> MySpace, che era un'applicazione discreta (basta leggere il report dell'attacco) letto >> é stato bucato non solo da un bug di codice (ma non, Andrea, dell'applicativo, ma del browser) >> ma anche da una proprietà  di una nuova architettura. eppure html.it ed il suo forum insegnano che la parola javascript va sempre splittata in java e script ... proprio tu mi parli di bug del browser ? Sappiamo tutti quante vulnerabilita' ha IE, loro abilitavano i tag senza usare un parser bbcode predefinito .... ok, non vuoi il bbcode, lasci scrivere i CSS agli utenti ? ... ma ci stiamo ??? >> Nuova. L'impatto di un remote scripitng con Flash é diverso dall'impatto di >> remote scripting con JavaScript, diciamo un rapporto di 1 a 1000, o 1 a 10000000? c'e' un client, c'e' un server, il codice del client lo possono leggere tutti come tutti possono leggere il codice di un SWF. Il concetto e' interagire in modo asincrono come flash fa da anni, rivaluta il tuo rapporto o almeno ridimensionalo, io stesso ho scritto ed uso una classe JavaScript basata su Ajax che fa la stessa identica cosa del LoadVars di Flash ... i problemi di sicurezza, eventualmente, sono gli stessi, per come la vedo io, i controlli vanno sempre fatti lato server, il client aiuta ma non risolve. Al massimo bisogna controllare eventuali chiamate forzate al JS ... e qui torniamo al punto precedente di questo mio reply. >> Naturalmente per chi continua a pensare "hei, il mio guestbook é a prova di bomba" >> c'é sempre un posto libero su Bugtraq. nessun applicativo é a prova di bomba, ma fare un parsing di codice decente dovrebbe essere la priorità  numero 1 tanto più su un sistema che ammette tags. Rimango esattamente della mia prima opinione, guardo il vostro dito, quello che indica ajax ... e penso agli svilupatori, quelli che hanno cannato.

andr3a
andr3a

Guardiamo sempre al dito, e in sicurezza informatica é sempre fatale sottovalutare le variabili. MySpace, che era un'applicazione discreta (basta leggere il report dell'attacco), é stato bucato non solo da un bug di codice (ma non, Andrea, dell'applicativo, ma del browser), ma anche da una proprietà  di una nuova architettura. Nuova. L'impatto di un remote scripitng con Flash é diverso dall'impatto di remote scripting con JavaScript, diciamo un rapporto di 1 a 1000, o 1 a 10000000? Naturalmente per chi continua a pensare "hei, il mio guestbook é a prova di bomba", c'é sempre un posto libero su Bugtraq. Saluti, Francesco.

Francesco
Francesco

concordo in pieno con andr3a

Andrea Paiola
Andrea Paiola

>> Il problema é che grazie al remote scripting si crea un nuovo processo di interazione client-server; processo nuovo per chi non conosce Flash, altrimenti é sempre il solito discorso, visto che LoadVars e d XML fanno praticamente la stessa cosa da anni. >> processo che, proprio per il suo essere in background, rimane oscuro all'utente. ma che non impedisce di fare un debug in fase di progettazione, quindi piu' che di colpa parlerei di svista o di non curanza sulla sicurezza / affidabilità  dell' applicativo ... a prescindere da ajax.

andr3a
andr3a

Beh, chiaramente il problema non é questo. Il problema é che grazie al remote scripting si crea un nuovo processo di interazione client-server; un processo che, proprio per il suo essere in background, rimane oscuro all'utente. Per ripetere le parole di Samy: "Time to actually access other pages. We would use iframes, but usually (even when hidden), iframes aren't as useful and are more obvious to the user that 'something else' is going on. So, we use XML-HTTP in order for the actual client to make HTTP GETs and POSTs to pages". Questo non é certo incolpare Ajax (?) ma semplicemente aprire gli occhi sui possibili problemi.

Francesco
Francesco

... senza parole, chiunque abbia fatto un semplicissimo guestbook sa benissimo che non deve essere ammesso alcun codice html nei profili o campi utente ... adesso incolpiamo ajax se il sistema l'ha fatto gente poco curante della sicurezza ?

andr3a
andr3a