Flash eccelle sotto molti punti di vista ed è utilizzato in diversi ambiti, ma vi è un aspetto dove i file swf sono conosciuti come disastrosi: la sicurezza.
Navigando sul web si può notare come molti siti che alla sicurezza tengono particolarmente (per esempio siti con giochi a premi), utilizzino file Flash.
In questo articolo vedremo perché gli SWF hanno la fama di file poco sicuri (e come di fatto lo siano), spiegando però in quale modo si può rendere più sicuro un progetto pur senza rinunciare alle potenzialità grafiche e di animazione.
Il perché della scarsa sicurezza
La scarsa sicurezza dei file SWF è dovuta principalmente al fatto di essere un formato non esclusivo (difatti Flash non è l'unico software in grado di generare file SWF) e questo ha reso possibile la nascita di decompilatori di SWF, programmi capaci di leggere l'intero contenuto di un file (azioni comprese) che nelle ultime versioni sono anche in grado di ricostruire, più o meno dettagliatamente, il file sorgente (FLA); questi software avrebbero lo scopo di aiutare gli sviluppatori che perdano i loro file sorgenti, di fatto però vengono usati anche per decompilare file SWF altrui (pratica illegale) e chiaramente fanno scendere la sicurezza degli swf a livelli drasticamente bassi. Se inseriamo una password all'interno di un SWF, bastano pochi secondi, a un mal intenzionato, per trovarla decompilando il nostro filmato.
Per contrastare il fenomeno dei decompilatori sono nati nel tempo anche degli offuscatori, che hanno il compito opposto: criptare il codice degli SWF in modo da non renderlo leggibile.
Solitamente gli offuscatori però sono creati da utenti singoli o piccoli gruppi, mentre i decompilatori quasi sempre hanno una software house (seppur piccola) alle spalle, con la conseguenza che l'efficacia degli offuscatori è limitata nel tempo.
Oltre a questo, la quantità di decompilatori è relativamente elevata, quindi risultava difficile rendere un metodo sicuro e illeggibile per tutti. Attualmente, di fatto, esiste un solo compilatore reputato abbastanza efficace e aggiornato (SWFEncrypt), mentre abbiamo diversi decompilatori (i più noti sono Actionscript Viewer, Sothink SWF Decompiler e Imperator FLA).
Errori comuni
Per quanto il formato SWF non sia molto protetto, spesso sono gli errori in fase di programmazione a rendere nulla la sicurezza. In particolare è un errore comune creare dei form di login con utente e password memorizzati interamente all'SWF.
Molti pensano di risolvere inserendo i dati in un file di testo esterno, ma decompilando il file si vede comunque il percorso del file e lo si può aprire direttamente per leggere i dati.
Anche le soluzioni basate su linguaggi server-side (che di fatto sono la via più sicura, come vedremo) lasciano a desiderare in alcuni casi, poiché vengono restituiti dallo script dei dati sensibili piuttosto che una semplice conferma dell'avvenuto login.
Un altro errore piuttosto comune, specialmente per sezioni realizzate interamente in Flash, è quello di lasciare attivo il menu da tasto destro. Questo permette di spostarsi all'interno dei fotogrammi del filmato manualmente, quindi qualsiasi utente con qualche click sul menu potrebbe entrare in una eventuale sezione riservata senza nemmeno dover inserire i dati.
In generale bisogna sempre tener conto che meno dati si mostrano in chiaro, più l'applicazione è sicura. Lo scambio di dati tra Flash e altre fonti non è "invisibile", si riesce comunque a risalire ai percorsi di destinazione e di conseguenza se anche le informazioni non sono all'interno dell'SWF può risultare semplice reperirle. Dobbiamo quindi tenere il più separati possibile i dati (che saranno gestiti lato server) dal lato grafico (a cui sarà adibito il file SWF), ma soprattutto quando è possibile semplicemente evitiamo l'utilizzo di Flash: per un form di login va benissimo una normale soluzione con linguaggi server-side, molto più adatti allo scopo. Non andiamo a creare problemi di sicurezza solo per offrire una grafica maggiormente animata!
Separare grafica e dati
Se in molti casi (moduli di iscrizione, login, alcune tipologie di gioco) si può rinunciare all'utilizzo di Flash, vi sono invece situazioni in cui il suo impiego consente di creare un prodotto di livello qualitativamente molto alto. Prendiamo, per esempio, la creazione di un gioco dinamico e interattivo come potrebbe essere un flipper: in questo caso Flash consentirebbe di animare facilmente le componenti del gioco e di offrire un'esperienza visiva accattivante per l'utente. Supponiamo però che il nostro gioco abbia dei punteggi e ogni mese il giocatore col miglior punteggio vinca un premio: la sicurezza assume un aspetto rilevante per evitare che qualche utente possa falsare il suo risultato.
Gli unici dati per la classifica saranno punteggio e nome dell'utente: a fine partita il file SWF chiederà il nome all'utente, quindi manderà il punteggio e il nome del giocatore a uno script server-side, incaricato a sua volta di scrivere il punteggio su un database.
Ma come possiamo evitare che un giocatore decompili il file SWF, scopra il percorso dello script e i nomi delle variabili usate, quindi con questi dati invii una coppia nome-punteggio fittizia al nostro script?
Controllare la provenienza dei dati
Una delle prime cose da valutare è la provenienza dei dati: controllando se la coppia di valori nome-punteggio proviene dall'swf situato sul dominio del gioco; solitamente i linguaggi server-side hanno dei comandi in grado di mostrare l'url da cui arrivano i dati, in alternativa potremo usare una variabile ma in quest'ultimo caso sarebbe facile modificare solo il valore dei punti lasciando inalterato l'url di riferimento.
Controlli progressivi durante il gioco
Un metodo piuttosto efficace può essere quello di effettuare dei controlli progressivi, ovvero, per esempio, mandare ogni X secondi il valore del punteggio al server: se riscontrassimo un punteggio piuttosto alto senza alcun valore precedente, sicuramente sarebbe falso. Anche questo metodo non offre certezze assolute, poiché decompilando il file un utente potrebbe vedere gli intervalli di tempo a cui viene inviato il controllo e replicarlo.
Controllo sul tempo di gioco
Conoscendo indicativamente il tempo di gioco plausibile per un determinato punteggio, possiamo controllare il numero di secondi (o minuti) impiegati dall'utente per raggiungere il suo punteggio e, se il punteggio è troppo elevato in rapporto al tempo, bloccarlo.
Sempre inerente il tempo vi è un altro controllo consigliabile, ovvero il tempo di invio tra un punteggio e l'altro: se arrivano più tentativi di invio da parte dello stesso utente in un lasso di tempo ridotto, si può pensare anche ad un blocco del nick o dell'IP di quell'utente.
Presi singolarmente questi controlli possono essere mediamente efficaci, ma abbinandoli otteniamo un livello di sicurezza accettabile.
Oltre a questo, possiamo criptare il codice del nostro SWF in modo che sia più difficile risalire all'Actionscript contenente gli url e le variabili di riferimento; per quanto come già accennato l'efficacia degli offuscatori spesso venga vanificata da nuove versioni dei decompilatori, SWFEncrypt sembra attualmente abbastanza efficace con i decompilatori maggiormente usati.
Basarsi sempre sul tipo di progetto
Abbiamo visto l'esempio di un gioco dove solo alla fine venivano inviati dei dati perché è la situazione "più a rischio", in quanto il punteggio deve comunque essere stabilito dal file Flash e partire da zero.
Vi sono situazioni in cui potremmo avere dei passaggi "progressivi"; pensiamo per esempio a un gioco dove l'utente deve prima puntare, poi giocare e infine eventualmente ritirare la vincita: in questo caso possiamo attuare un ulteriore controllo, cioè a ogni stato devono corrisponderne di precedenti (così possiamo evitare che l'utente esegua in maniera fittizia solo l'azione di incasso, senza giocare!).
Anche in un software si possono attuare controlli di questo tipo, ma sono casi relativamente più rari in quanto per un programma è prevedibile almeno un login per impedire l'accesso a utenti non autorizzati e per il login abbiamo già detto come sia possibile evitare Flash per conservare un maggior livello di sicurezza.
Questo per sottolineare come in base al progetto cambino le esigenze di sicurezza e di conseguenza le contromisure da adottare lato server. Se sui file SWF, infatti, l'unica forma di protezione è l'offuscamento / criptazione del codice Actionscript, oltre ovviamente all'accortezza di non inserire troppe informazioni in chiaro nel codice Actionscript, lato server abbiamo la possibilità di controllare molti più dati e valutare se siano attendibili o "sospetti".
Conclusioni
Possiamo concludere dicendo che il formato SWF sicuramente non garantisce una buona sicurezza, ma se sfruttato nell'ambito grafico, lasciando la gestione dei dati e i controlli a un linguaggio lato server può costituire un ottimo valore aggiunto nei nostri progetti. Molti dei problemi di sicurezza imputati agli SWF di fatto sono causati da un uso errato di questi file: un modulo di login in Flash non ha quasi mai senso di esistere, specialmente se deve proteggere dati importanti.
Imparando a effettuare i controlli appropriati in base al progetto e delegando l'SWF solo alla parte grafica e all'invio minimo di dati al server, potremo implementare soluzioni sicure e fornite di una grafica accattivante.
