L'insostenibile insicurezza del Web

JavaScript, una delle tecnologie al cuore delle pagine web dinamiche, si trova sotto il fuoco incrociato di vari esperti di sicurezza che, di recente, hanno scoperto nuove vulnerabilitÓ del linguaggio

Roma - La tecnologia JavaScript, che gli esperti di sicurezza considerano da tempo uno dei più grossi punti deboli dei browser web, rischia di minare le fondamenta anche del giovane Web 2.0. A dirlo è Fortify Software, che ha pubblicato un advisory (datato 12 marzo ma reso pubblico solo negli scorsi giorni) in cui descrive una nuova classe di vulnerabilità del web battezzata JavaScript Hijacking. Come se non bastasse, questa stessa settimana è stato pubblicato su Internet il codice di un programma, chiamato Jikto, che sfrutta proprio JavaScript per trasformare un browser in un potente tool di cracking.

Fortify spiega che un crescente numero di applicazioni AJAX (il più noto modello di sviluppo alla base del Web 2.0) utilizza JavaScript come meccanismo di trasporto dei dati. Niente di più sbagliato, secondo la società californiana: questa pratica renderebbe le web application particolarmente vulnerabili ad attacchi che, bypassando le restrizioni di sicurezza dei browser (ed in particolare la Same Origin Policy), permettono ai cracker di leggere le informazioni confidenziali contenute all'interno dei messaggi JavaScript (password, cookie, numeri di carta di credito ecc.).

L'azienda ha spiegato che nel recente passato si sono già scoperti alcuni siti web vulnerabili al JavaScript Hijacking, ed uno dei primi è stato il celebre Google Gmail. Vulnerabili, secondo la scocietà, anche i principali framework per lo sviluppo di applicazioni AJAX, inclusi ASP.NET e Google Web Toolkit (GTW), e alcune delle più note librerie client-side, come Dojo, Yahoo! UI, Rico, ecc.
La società afferma tuttavia che la responsabilità di scrivere codice sicuro spetta soprattutto allo sviluppatore, il quale ha sempre il compito di verificare il codice e applicare le più comuni best practice in fatto di sicurezza. Pronta la risposta di Google, che sul proprio sito ha recentemente dedicato agli sviluppatori di GTW una serie di suggerimenti su come evitare le vulnerabilità di JavaScript.

A mette a nudo le debolezze di JavaScript c'è anche il già citato Jikto, un tool scritto dal ricercatore di SPI Dynamics Bill Hoffman e presentato nel corso della conferenza hacker ShmooCon tenutasi poche settimane fa. Hoffman non aveva ancora reso il proprio tool di pubblico dominio, ma una delle persone che lo aveva ricevuto in prova lo ha uploadato sul proprio sito web: il programma è rimasto online poche ore, ma in questo arco di tempo è stato scaricato da oltre un centinaio di utenti.

Jikto non è stato pensato come tool di cracking: si tratta sostanzialmente di uno scanner di vulnerabilità scritto interamente in JavaScript. Il problema, secondo Hoffman, è che un abile cracker può facilmente sfruttarne il codice per scrivere programmi molto pericolosi capaci di creare una sorta di botnet e di collezionare i dati sensibili di utenti e siti web.

Jikto può essere inoculato da un aggressore in un sito web sfruttando il tipo di vulnerabilità più diffuso sul Web, il cross-site scriping (XSS), e come spiegato da The Inquirer è in grado di agire sia lato client (il browser) che lato server, diffondendosi da una all'altra "sponda" in modo autonomo. Grazie alle proprietà di JavaScript, il programma di Hoffman può funzionare su tutti i principali browser in circolazione, incluse le ultime versioni di Firefox, Internet Explorer, Opera e Safari. Una descrizione del tool è stata pubblicata qui lo scorso mese anche da zone-h.it.

Gli esperti affermano che il modo più rapido e sicuro per difendersi dagli attacchi basati su JavaScript consiste nel disattivare questa tecnologia all'interno del proprio browser: così facendo, però, ci si preclude la possibilità di godere della stragrande maggioranza dei contenuti dinamici presenti su Web.
41 Commenti alla Notizia L'insostenibile insicurezza del Web
Ordina
  • Probabilmente non hai mai usato NoScript, che è di gran lunga più semplice da usare e sicuro delle "site preferences" di Opera.

    http://noscript.net
    -----------------------------------------------------------
    Modificato dall' autore il 04 aprile 2007 13.21
    -----------------------------------------------------------

  • - Scritto da: Giorgio Maone
    > Probabilmente non hai mai usato NoScript, che è
    > di gran lunga più semplice da usare e sicuro
    > delle "site preferences" di
    > Opera.
    >
    > http://noscript.net
    > --------------------------------------------------
    > Modificato dall' autore il 04 aprile 2007 13.21
    > --------------------------------------------------

    Ne deduco che Lei non abbia mai usato Opera.
    non+autenticato
  • - Scritto da:
    >
    > - Scritto da: Giorgio Maone
    > > Probabilmente non hai mai usato NoScript, che è
    > > di gran lunga più semplice da usare e sicuro
    > > delle "site preferences" di
    > > Opera.
    > >
    > > http://noscript.net
    > >
    > --------------------------------------------------
    > > Modificato dall' autore il 04 aprile 2007 13.21
    > >
    > --------------------------------------------------
    >
    > Ne deduco che Lei non abbia mai usato Opera.

    Perdoni il tu, mi ero permesso perché il messaggio originale sembrava scherzoso e informaleOcchiolino

    Ho usato tanto Opera 8.x (che non aveva alcuna funzionalità paragonabile a NoScript) quanto Opera 9.x, le cui "Site preferences", per quanto rappresentino un passo avanti, sono sempre meno usabili e precise di NoScript.
  • - Scritto da: Giorgio Maone
    > Ho usato tanto Opera 8.x (che non aveva alcuna
    > funzionalità paragonabile a NoScript) quanto
    > Opera 9.x, le cui "Site preferences", per quanto
    > rappresentino un passo avanti, sono sempre meno
    > usabili e precise di
    > NoScript.

    Quoto e sottoscrivo, avendo utilizzato intensivamente entrambi i browser (con differenti sistemi operativi) ed essendo utilizzatore di NoScript fin dalla versione 1.0.2

    Opera ha aggiunto solo di recente una funzionalità (le "site preferences" appunto) vagamente simile a NoScript, che non è altrettanto flessibile e immediata, nè altrettanto semplice e intuitiva nell'utilizzo. Opera è un ottimo browser, leggero e veloce, senz'altro superiore a IE sotto tutti i punti di vista, ma dal punto di vista della sicurezza, Firefox è meglio, grazie alla frequenza degli aggiornamenti e soprattutto grazie ad estensioni come AdBlock e NoScript (ottimo anche FlashGot, dello stesso autore, cui da Pythoniano e utente Django perdono la preferenza per Ruby on RailsSorride e che avviso contestualmente che questo Forum è un noto covo di perniciosi Troll Troll chiacchierone )

    P.S.:
    Fan Commodore64
  • ... come sfruttare vulnerabilità su Ajax?
    Framework vari a parte... dal lato prettamente javaScript della cosa come è possibile sfruttare la vulnerabilità se il contenuto (i dati) sul server sono accessibili solo in caso di autenticazione avvenuta???
    non+autenticato
  • Supponi che tu sia già autenticato (o addirittura che l'autenticazione sia "automatica", come accade quando attivi le funzioni "ricordati di me" offerte con leggerezza da numerosi siti).

    Nel frattempo continui a navigare altri siti con noncuranza, magari in un altro tab o in un'altra finestra...

    Qualunque richiesta, effettuata a partire da qualunque sito, la cui destinazione sia il sito in cui sei autenticato, invia i cookie di quel dominio (tra i quali quello che ti identifica come utente autenticato): a tutti gli effetti la richiesta abusiva "appare" autenticata. Non è un bug: così funziona il web.

    L'attacco recentemente definito "JavaScript Hijacking" non fa altro che "mimare" una richiesta AJAX legittima e autenticata, utilizzando il tag <script>, e attingere i dati "interessanti" contenuti nella risposta usando una delle diverse tecniche permesse dal fatto che JavaScript è un linguaggio dinamico (ad esempio la ridefinizione del prototipo Object).

    L'advisory citato dall'articolo (http://www.fortifysoftware.com/advisory.jsp) descrive nel dettaglio sia l'attacco che le contromisure che dovrebbero essere prese dagli sviluppatori di siti AJAX.

    L'unica difesa disponibile per l'utente è disattivare JavaScript globalmente ed eventualmente attivarlo solo sui siti "fidati", cosa che può essere più o meno agevole.
    Il sistema più facile e comodo è NoScriptSorride

    http://noscript.net
  • - Scritto da: Giorgio Maone
    > L'attacco recentemente definito "JavaScript
    > Hijacking" non fa altro che "mimare" una
    > richiesta AJAX legittima e autenticata,
    >
    > L'advisory citato dall'articolo
    > (http://www.fortifysoftware.com/advisory.jsp)
    > descrive nel dettaglio sia l'attacco che le
    > contromisure che dovrebbero essere prese dagli
    > sviluppatori di siti
    > AJAX.

    Leggo che funziona solo se si usa JSON.
    Frega un tubo, visto che io uso XML puro, che sarà leggermente più pesante in termini di CPU, ma chissenefrega, visto che parliamo di differenze ridicole di frazioni di secondo, nei casi normali! Usare eval su dei dati passati via server/client mi ha sempre dato i brividi.

    Problemi non banali noti con XML?
  • [Avviso obiettività: lo scrivente è l'autore di NoScript, http://noscript.net ]

    I problemi legati a JavaScript di cui si comincia a parlare sono per lo più frutto di negligenza, ignoranza, distrazione o fretta da parte degli sviluppatori di siti Web, ma non di meno sono diffusissimi (basti dare un'occhiata a quanto ci si diverte in questo forum: http://sla.ckers.org )

    Se il sito vulnerabile è un portale di giochi on line e di mezzo non ci sono i miei soldi o la mia privacy, passi.

    Ma se invece si tratta di online banking o di web mail, e comunque in tutti i casi in cui lo sfruttamento della vulnerabilità procuri all'utente un danno economico o morale, credo che la responsabilità civile possa essere un buon incentivo a migliorare la formazione e l'attenzione alla sicurezza da parte dei dipartimenti IT (naturalmente, il parere di un avvocato o di un'associazione di consumatori sulla reale fattibilità, stanti le norme vigenti, è gradito).

    Ma a parte intentare cause e chiedere risarcimenti, all'utente cosa resta da fare, specialmente per difendersi durante la navigazione "casuale" di siti anonimi o peggio maligni che sarebbe ridicolo pensare di portare in tribunale?

    NoScript ( http://noscript.net ) serve proprio a questo: attiva JavaScript, Java, Flash ed altre tecnologie dinamiche solo sui siti "fidati", e le blocca preventivamente su tutti gli altri. L'equivalente web di "non aprire la porta agli sconosciuti", senza contare che molti siti web, specialmente quelli informativi, si "vedono bene" anche "dallo spioncino" (senza scripting in azione).

    Ovviamente, resta da definire cosa sia un sito fidato: per me è quel sito il cui responsabile può essere identificato, rintracciato e se necessario querelato, o che comunque gode di una tale reputazione da rendere le falle estremamente improbabili (anche se non impossibili, vedi la rubrica di GMail) per il danno d'immagine che ne deriverebbe.

    Giusto i miei due centesimi di euroSorride

    http://noscript.net

  • ...

    > Ma se invece si tratta di online banking o di web
    > mail, e comunque in tutti i casi in cui lo
    > sfruttamento della vulnerabilità procuri
    > all'utente un danno economico o morale, credo che
    > la responsabilità civile possa essere un buon
    > incentivo a migliorare la formazione e
    > l'attenzione alla sicurezza da parte dei
    > dipartimenti IT (naturalmente, il parere di un
    > avvocato o di un'associazione di consumatori
    > sulla reale fattibilità, stanti le norme vigenti,
    > è
    > gradito).

    Quoto in toto; anch'io voterei per la Responsabilitß Civile. Il mondo informatico cambierebbe moltissimo e solo in meglio.
    Ci sono perˇ troppi intoppi, primo fra i quali il fatto che la contromossa del 99% dei siti sarebbe un bel disclaimer in prima pagina.
    Rendi il disclaimer fuori legge?
    In questo caso, ogni Pinco Pallino blogger avrebbe una immensa paura di pubblicare il suo sito/blog, almeno che non possa scaricare la colpa direttamente sul produttore del software invece che fare una semplice rivalsa (ti voglio vedere a rifondere gli utenti danneggiati coi famosi 5$ a copia per Windows).

    Inoltre il livello di sicurezza necessario per una RC sui siti richiede programmatori specializzati che giß mancano. Giß non ci sono (a livello mondiale) abbastanza programmatori sufficientemente abili da far funzionare bene un sito od un software; con la RC figuriamoci!
    ...ed in pi˙, programmatori come me che si possono definire almeno decenti e si ritengono degli deiA bocca aperta non sanno assolutamente niente di sicurezza e tecniche come code injection.
    La strada non é lunga. ╔ infinita.
  • Un pc scollegato da internet.

    E datemi torto.
    non+autenticato

  • - Scritto da:
    > Un pc scollegato da internet.
    >
    > E datemi torto.

    meglio ancora... un PC spento, ancora più sicuro...

    che discorsi... se ti serve internet che fai coltuo pc scollegato?
    non+autenticato

  • - Scritto da:
    >
    > - Scritto da:
    > > Un pc scollegato da internet.
    > >
    > > E datemi torto.
    >
    > meglio ancora... un PC spento, ancora più
    > sicuro...

    Sbagliato! Con il Wake On Lan attivo ed una NAT sul router automaticamente collegato, ti accendo il PC e te lo cracco!!
    Tié!! Con la lingua fuori
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 9 discussioni)