Segnalibri al 27 aprile 2011

Cloud

  • Access all your data. Anytime, anywhere, from any device.

    Tags: #backup #storage #sync

    16 aprile 2011

  • For the past several days I have been focused on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts that may be left on a system as a result of using these tools. Given the prevalence of Dropbox, I decided that it would be one of the first synchronization tools that I would analyze, and while working to better understand it I came across some interesting security related findings. The basis for this finding has actually been briefly discussed in a number of forum posts in Dropbox’s official forum (here and here), but it doesn’t quite seem that people understand the significance of the way Dropbox is handling authentication. So, I’m taking a brief break in my forensics-artifacts research, to try to shed some light about what appears to be going on from an authentication standpoint and the significant security implications that the present implementation of Dropbox brings to the table.

    Tags: #dropbox #security #authentication

    13 aprile 2011

  • I also urge the company to abandon its deduplication system design, and embrace strong encryption with a key only known to each user. Other online backup services have done it for some time. This is the only real way that data can be secure in the cloud.

    Tags: #dropbox #security #encryption

    13 aprile 2011

  • Tarsnap is a secure online backup service for BSD, Linux, OS X, Solaris, Cygwin, and can probably be compiled on many other UNIX-like operating systems. The Tarsnap client code provides a flexible and powerful command-line interface which can be used directly or via shell scripts.

    Tags: #backup #encryption #security

    13 aprile 2011

Leggi tutto “Segnalibri al 27 aprile 2011”

Quando il feed RSS di WordPress fa i capricci

Come ho risolto un problema di validazione del feed RSS di un blog.

Ricordo che anni fa capitò anche a me. Allora non ero così a mio agio nei meandri di questo CMS e la cosa mi spiazzò. In parole semplici, il feed RSS di WordPress non veniva convalidato dai browser e nemmeno da FeedBurner, rimanendo quindi irraggiungibile per i lettori: c’era un errore nel parsing del file XML. Ricordo bene che il problema era dovuto a qualche riga vuota all’inizio (o alla fine) del file, ma non ricordo come ne uscii. Avrò senz’altro cercato aiuto su Google e, a giudicare dalla mole di risultati che ne escono fuori, sembra un problema capitato a tanti altri.

Questo problema si è presentato in questi giorni in un blog (che non amministro) e, chiaramente, il primo consiglio che si dà in questi casi è quello di disabilitare tutti i plugin, mettere il tema standard di WordPress (oggi TwentyTen, domani sarà TwentyEleven) e forzare l’aggiornamento della cache di FeedBurner (se si usa questo servizio). Nonostante questi passaggi, il problema persiste. Consiglio, quindi, di aggiornare a WordPress 3.1.2, visto che vengo anche a sapere che la versione in uso era la 3.1.1, ma niente da fare. Ottenuto l’accesso via FTP, decido di procedere a un aggiornamento manuale. Mentre osservavo l’upload dei file, lo sguardo mi cade sul file wp-config.php che — ovviamente — viene saltato nell’aggiornamento e mi domando:

E se fosse lui, il problema?

Intuizione corretta! Finito l’upload di tutti i file del core, compresi quelli del tema TwentyTen, e constatato che neanche questa soluzione era efficace, mi butto sul file in questione. Con un piacere quasi sadico mi accorgo che il file si chiudeva in questo modo:

?>
// riga vuota
// riga vuota

cioè con il tag di chiusura di PHP 1 più due righe vuote alla fine del file. Elimino il tag di chiusura del file: le righe vuote alla fine del file non mi interessano più, una volta che quel tag è stato eliminato e uploado il file corretto.

Magia!

Bonus extra. Dai uno sguardo al tuo file wp-config.php che magari ti porti dietro da anni e accertati che le righe delle chiavi di sicurezza siano 8. Se non sono 8, prelevale dal WordPress.org secret-key service e sostituisci quelle che hai in quel file. Per entrare, poi, in bacheca dovrai autenticarti nuovamente.

Note

  1. Tra l’altro, mi chiedo, perché in WordPress è così onnipresente questo tag di chiusura?