Mike Murray, chief information security officer di Foreground Security, in questo articolo ha richiamato l’attenzione della comunità di esperti di sicurezza su una vulnerabilità legata a Flash e considerata potenzialmente molto seria. Una vulnerabilità che, secondo l’esperto, non deriva da un bug nel codice di Flash Player ma da alcune regole di sicurezza della tecnologia di Adobe e da come queste vengono interpretate dagli sviluppatori web.
Stando a quanto spiegato da Murray, la debolezza potrebbe essere utilizzata per trasformare in veicoli di diffusione di script maligni la stragrande maggioranza dei siti web che consentono agli utenti di caricare file. Come dimostrerebbe questo video pubblicato da Mike Bailey, ricercatore senior di Foreground, tra le risorse vulnerabili c’era anche Gmail (Google ha recentemente corretto il problema): in questo caso il vettore di attacco era rappresentato dagli allegati email.
“Tra i siti web potenzialmente vulnerabili ci sono quelli di social networking, quelli dedicati alla carriera lavorativa, quelli delle agenzie governative e delle aziende della Fortune 1000”, ha messo in guardia Bailey. “Questa falla è particolarmente insidiosa per il fatto che i contenuti Flash possono essere mascherati da altri tipi di file, come documenti Word ed Excel, immagini o file zip”. L’esperto ha citato come esempio l’eventualità che l’utente di un forum carichi sul server un file che, pur sembrando l’immagine di un avatar, è invece un file Flash maligno capace di compromettere la sicurezza di tutti coloro che semplicemente visualizzino il finto avatar.
Murray e Bailey hanno spiegato che il problema risiede nella same-origin policy di Flash ActionScript e nel modo in cui questa viene generalmente interpretata dagli sviluppatori. “Le regole alla base della same-origin policy di ActionScript sono molto simili a quelle di JavaScript: un oggetto Flash può accedere esclusivamente ai contenuti che risiedono sullo stesso dominio da cui è stato eseguito lo script” spiegano i due ricercatori. “La differenza più importante è che gli oggetti Flash non sono pagine web. Non c’è bisogno di iniettare un oggetto Flash all’interno di una pagina web per eseguirlo: è sufficiente caricare il contenuto. Ciò significa che se io metto un oggetto Flash sul tuo server, posso eseguire degli script nello stesso contesto del tuo dominio”.
Interrogata sulla questione, Adobe ha dichiarato a Foreground che “sfortunatamente non c’è una soluzione semplice”, e il motivo è che “è molto difficile risolvere il problema senza compromettere il funzionamento dei contenuti legittimi sparsi per il Web”. La mamma di Flash ritiene sia molto più proficuo “educare” sviluppatori e web designer a comprendere tutti gli aspetti della same-origin policy di Flash ActionScript, in modo da aggirare il problema in fase di creazione dei siti web.
Murray ha precisato che al momento non ci sono segnalazioni di attacchi che facciano leva su questa debolezza, tuttavia “ci sono prove che dimostrano come i cracker si stiano muovendo in questa direzione”.
Alessandro Del Rosso
-
uhm...
1-come hanno fatto a testarlo sui 25 principali siti globali se questi usano l'http? mica da una aprte puoi avere http e dall'altra spdy2-le adsl italiane vanificheranno tuttoboh.Re: uhm...
1- Basta averne una copia dei siti nel loro server o chiedere a quei 25 siti di partecipare alla sperimentazione. Più probabile sia la prima...2- Non credo sia così: grazie alle tecniche di compressione e multi-connessione nuove accennate nell'articolo, anche noi poveri italiani potremo avere benefici da questo nuovo protocollo.Se magari permettessero anche una crittografia dei dati, soprattutto per quanto riguarda i dati inviati da client a server (password e altri dati sensibili) come fa l'https, ma con molta più "semplicità tecnica", direi che arriverà a sostituire l'http egregiamente.-----------------------------------------------------------Modificato dall' autore il 13 novembre 2009 20.52-----------------------------------------------------------kaihiwatariRe: uhm...
La crittografia la permette... anzi... la rende obbligatoria da specifiche (leggiti la documentazione).Ma questo è il problema !La crittografia andrebbe usata solo ed esclusivamente quando vengono inviati dati riservati (login, carte di credito, informazioni personali o confidenziali ecc...)... se devo trasferire il logo di una società, lo sfondo di un sito, una musica di sottofondo, una homepage, una pagina informativa generica e via dicendo non serve oberare i server web di lavoro del tutto inutile (criptare porta via moltissimo CPU time).StarRe: uhm...
Ammetto di non aver letto la documentazione, appena avrò un po' di tempo gli darò un'occhiata!Beh il tuo "moltissimo" mi sembra un po' troppo: anche le odierne CPU per netbook possono fare senza sforzi tali lavori di crittografia.E poi, crittografare anche i dati non proprio riservati non mi sembra esattamente uno spreco: che gli altri si facciano un po' gli affari propri su cosa visito o no! ;Dkaihiwatariun altro flash
..stesso discorso fatto per flash: siti che caricano contenuti piu' velocemente, contenuti piu' performanti, affiancamento e non sostituzone dell'html... tutto gia' sentito, ecco a voi un altro plugin, l'ennesimo.., per carita' sara' pure tutto vero, veloce bello leggero etc etc, ma apparentemente (sottolineato) non e' lo standard che viene sostituito, ma semplicemente un addon da pluggare nei browsers.free for allRe: un altro flash
Header compressi, significa che i Webserver devono supportare l'invioche inizialmente i browser possano supportarli grazie ad un plug-inquesto è vero, ma alla fine con le release nuove la cosa verrebbeintegrata a livello di codice del Browser, e onestamente andrebberivisitato anche il protocollo TCP/IP, ormai è come i PC il collodi bottiglia è sempre più legato ai protocolli di base che sono fermiall'epoca degli anni 80.Be&ORe: un altro flash
Guarda che i protocolli attuali sono piu' leggeri che quelli che vorrebbero fare...A meno che vuoi usare UDP, ma non credo sia una buona idea...rido per non piangereRe: un altro flash
- Scritto da: Be&O> andrebbe> rivisitato anche il protocollo TCP/IP, ormai è> come i PC il> collo> di bottiglia è sempre più legato ai protocolli di> base che sono> fermi> all'epoca degli anni 80.Siamo sicuri?No, lo dico perché TCP/IP, HTTP e compagnia sono stati progettati in un periodo dove era lenta la trasmissione di ogni singolo byte, e le risorse erano limitate. Detto questo, mi aspetto che oggi non siano i protocolli il problema, visto che abbiamo reti di 3-4 ordini di grandezza più veloci e i sistemi innumerevolmente più potenti e veloci!Certo, se un protocollo era nato per fare una cosa e due decenni dopo viene usato per scopi diversi, è ragionevole pensare a rinnovarlo...Boh, staremo a vedere... speriamo solo che pubblichino tutte le specifiche in modo aperto!gerlosRe: un altro flash
No.L'articolo parla di protocollo.Il protocollo non è un plugin.Per cortesia..Skhammyil solito show di luci e colori di guggl
SPDY is intended to be as compatible as possible with current web-based applications. This means that, from the perspective of the server business logic or application API, nothing has changed. To achieve this, all of the application request and response header semantics are preserved. SPDY introduces a "session" which resides between the HTTP application layer and the TCP transport to regulate the flow of data. This "session" is akin to an HTTP request-response pair. The following changes represent the differences between SPDY and HTTPe qui ci si rende conto delle "belle idee" di guuglovvero questa idea geniale che dovrebbe risolvere la velocita' dell'http produrra' (una persona con un minimo di conoscenza informatica potrà comprendere) dei bellissimi imbutoni a livello di tcp/ip eh si sono proprio dei geni.RIVOGLIO altavista!spectatorRe: il solito show di luci e colori di guggl
dei bellissimi imbutoni a livello di tcp/ip ??? Ci facci comprendere, plis ...GattazzoRe: il solito show di luci e colori di guggl
Concordo. La latenza aiuta a rendere fluido il traffico.ruppoloRe: il solito show di luci e colori di guggl
- Scritto da: spectator> RIVOGLIO altavista!Altavista c'è ancora.Altavista ha una interfaccia più pesante di quella di Google.pinco pallinoRe: il solito show di luci e colori di guggl
Altavista usa lo stesso indice di Yahoo (a quanto dice wikipedia), quindi ti fornirebbe gli stessi risultati; tanto vale usare yahoo, a questo punto.angrosRe: il solito show di luci e colori di guggl
- Scritto da: angros> Altavista usa lo stesso indice di Yahoo (a quanto> dice wikipedia), quindi ti fornirebbe gli stessi> risultati; tanto vale usare yahoo, a questo> punto.Forse gli stessi risultati ma non nello stesso modo, tantopiù che gli stessi risultati per esempio non sono supportati dal plugin di Web Of Trust.Quindi è effettivamente meglio usare Yahoo (che per la cronaca fornisce risultati migliori del vecchio altavista).pinco pallinoRe: il solito show di luci e colori di guggl
magari il problema sono proprio le latenze non ti pare?se poi telecom non ce la fa a raggere già il traffico attuale, beh, google che colpa ne ha?google sta nel 2010, se noi qui siamo nel 1910 non è un problema di googlel'idea di google riduce il consumo di banda e abbassa le latenze e questo è un benepabloskiBasta che sia un protocollo open
Come da titolo :)MattiaRe: Basta che sia un protocollo open
dev'esserlo per forza, altrimenti chi lo userà?pabloskiRe: Basta che sia un protocollo open
- Scritto da: Mattia> Come da titolo :)http://dev.chromium.org/spdy/spdy-protocoltizio incognitoRe: Basta che sia un protocollo open
Open a me non basta, dovrebbe essere "standard"GiovanniIl vero problema di SPDY...
...lo scoprite leggendo nella documentazione il paragrafo: "Goals for SPDY", per l'esattezza il punto che dice:"To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken."Tutti vogliono connessioni sicure e criptate. Ma vi siete mai chiesti perché molti siti che devono/vogliono garantire solo la sicurezza dell'autenticazione ma non dei contenuti trasferiti (es. Hotmail) usano l'HTTPS solo in fase di login per generare un token e poi passano all'HTTP ?Criptare il traffico ha un costo in termini di tempi di elaborazione non indifferente. I grossi provider non a caso fanno uso di moduli hardware dedicati nei propri server per questi compiti. Ma persino tali moduli non hanno potenze di calcolo infinite.Immaginatevi ora se tutti i server web decidessero di supportare SPDY come protocollo. Qualsiasi pagina web, anche la homepage di un'azienda o un blog, un forum o quant'altro nonché tutti gli elementi grafici e le applicazioni Flash/Java ad essi connessi verrebbero criptati. Per non parlare dei file da scaricare, magari centinaia di Mega o Giga... tutto criptato da specifiche.Quanto credere che reggerebbero i server web attuali, anche i più potenti ? Ed upgradarli per riuscire a reggere un simile carico computazionale quanto pensate che verrebbe a costare ?StarRe: Il vero problema di SPDY...
Fra 3 anni sarà la norma, ricorda la legge di moore....Steve Robinson HakkabeeRe: Il vero problema di SPDY...
Potrebbe anche essere NSA ed i governi a volere dati di email passare in chiaro nelle connessioni...iRobyRe: Il vero problema di SPDY...
- Scritto da: Star> Tutti vogliono connessioni sicure e criptate. Ma> vi siete mai chiesti perché molti siti che> devono/vogliono garantire solo la sicurezza> dell'autenticazione ma non dei contenuti> trasferiti (es. Hotmail) usano l'HTTPS solo in> fase di login per generare un token e poi passano> all'HTTP?Probabilmente perché su servizi gratuiti il loro interesse è quello di rendere sicura l'acquisizione delle credenziali d'acXXXXX.Immagino che con caselle e-mail a pagamento invece si possa avere una connessione completamente criptata.UbuntoGrazie, il tuo commento è in fase di approvazioneGrazie, il tuo commento è stato pubblicatoCommento non inviatoGrazie per esserti iscritto alla nostra newsletterOops, la registrazione alla newsletter non è andata a buon fine. Riprova.Leggi gli altri commentiPubblicato il 13 nov 2009Ti potrebbe interessare