Quando si progetta un sito è necessario fare molta attenzione alla progettaizone lato codice, specie se nelle istruzioni sono coinvolte operazioni che abbiano a che fare con form e manipolazione di URL. Questo genere di accortezze, in genere, derivano dall’esperienza di chi programma, e sono sempre all’ordine del giorno per chi progetta i CMS open source (Drupal, Joomla!, WordPress, Magento…) che tutti utilizziamo quotidianamente: tuttavia l’attenzione deve essere sempre molto vigile, da parte di tutta la comunità di sviluppatori, e non esitiamo soprattutto a segnalarne di eventuali qualora dovessimo accorgerci di qualcosa che non va.
Nella comunità WordPress, ad esempio, di recente è stato discusso un aspetto importante, attualmente sottovalutato dagli sviluppatori: ovvero che l’URL dell’autore sia spesso indicizzato da Google (ad esempio wordpress.com/author/pippo), e che da esso si possa risalire con facilità al nome dell’utente amministratore (pippo). In questo modo gli attacchi basati su dizionario, oppure quelli brute-force, sono enormemente facilitati, e non sempre possiamo prendere tutte le adeguate contromisure, per quanto sia possibile certamente migliorare, ogni giorno, il livello di sicurezza del proprio blog o sito web.
Di seguito riportiamo alcuni esempi di classiche debolezze dei siti web (l’elenco non è completo, ma è comunque significativo), con relative contromisure che si possono prendere, e senza riferimento ad un CMS particolare bensì, ad esempio, ad un ambiente di sviluppo per siti molto diffuso come PHP+MySql+Apache.
API Abuse
Tipicamente le API servono perchè un servizio web esterno possa essere richiamato da un sito lato codice: è il caso dell’autenticazione sui siti web mediante Facebook ad esempio. L’abuso in questione si verifica qualora il chiamante possa accedere ai servizi aggirando la procedura di autenticazione, ad esempio eseguendo operazioni non consentite. La base di questo genere di attacchi è insita nella logica dell’hacker stesso, che di fatto sa che tipo di risposta attendersi da determinate chiamate remote e si comporta di conseguenza.
Hard-coded Password
Un problema molto comune nei siti web: le password non solo sono memorizzate in chiaro, ma in fase di sviluppo vengono salvate ad esempio all’interno di commenti che poi compaiono nel codice HTML. In fase di sviluppo del software comunque è molto comune fare uso di questo genere di procedure, specie per velocizzare la produzione del codice: è quindi necessario verificare scrupolosamente che non siano presenti password in chiaro in nessun punto del codice, nè come commenti PHP (che comunque non compaiono nel markup HTML) nè tantomeno in output in chiaro, neanche in forma di commenti.
Esempio:
Password aging non consentito
Come accennato nell’articolo di ieri, a volte non è possibile fare in modo di aggiornare la propria password nel tempo, facilitando così in parte la possibilità che venga indovinata, nel tempo da qualcuno. I sistemi di posta elettronica sono molto evoluti sotto questo punto di vista, ed alcuni sistemi di banking obbligano l’utente a cambiare password ogni mese per questo motivo.
Password deboli o vuote
È bene ricordare ancora una volta che le password non dovrebbero mai essere composte da sequenze di numeri troppo banali (131313 ad esempio), nè da parole semplici (password, ciao) ed è molto meglio che contengano almeno un carattere come ., !, o ? assieme ad un mix di lettere e numeri. Lasciare le password vuote non è mai una buona idea: nei sistemi moderni di ogni tipo la parola d’ordine ha sempre una propria utilità e non dovrebbe essere aggirata dagli utenti stessi.
Password Plaintext
Simile al caso precedente, con la differenza che questa volta la password viene salvata in un file di testo del sito – che magari Google indicizza inavvertitamente – oppure in un file di configurazione come il file .htaccess, visibile pubblicamente. Meglio quindi non salvare le proprie password in nessun posto, e cercare di stabilire una propria politica per ricordarle anche se leggermente più complicate.
Memory Leak
Un memory leak si verifica per cause varie, e consta in un sostanziale incremento della memoria occupata che porta, nel lungo periodo, all’occupazione totale della memoria del sito e conseguente down o blocco. In questi casi la RAM viene occupata senza essere liberata, e questo avviene tipicamente per due ragioni:
- condizioni di errore in circostanze eccezionali (cosiddette “eccezioni”);
- confusione nello stabilire “chi abbia causato cosa” all’interno del codice del sito o del programma.
Violazioni di accesso
Si verificano qualora, ad esempio, andiamo ad accedere alle variabili private di uan classe PHP per restituirle in chiaro con un apposito metodo get(); basta seguire le comuni norme di buona programmazione ad oggetti (OO) per evitare queste circostanze. Esempi di tale vulnerabilità possono essere:
- dichiarazioni di array di variabili public e static
- campi pubblici che dovrebbero essere privati
- campi privati che vengono indebitamente restituiti da una funzione, magari per fare prima ed aggirare la logica della classe.
Vulnerabilità di path
Tale ultimo tipo di vulnerabilità, di fatto, permette ad un estraneo di navigare liberamente nelle cartelle del sito (se è un CMS noto, soprattutto), e nella possibilità ulteriore di eseguire file arbitrari direttamente dal browser. Gli input utente di URL e form, di fatto, qualora non siano validati tendono a provocare questo genere di problemi, che in casi estremi permettono all’attaccante di navigare liberamente sull’interno server virtuale.
