Categoria: Programmazione

  • Countdown personalizzato

    Come sviluppatore ho una decisa avversione verso il sistema di computo del tempo attualmente in uso.

    Utilizzare cicli nidificati con periodi variabili da 7 a 24 a [28,29,30,31] a [59,60,61] a [365,366] unità per contare la medesima cosa non è esattamente quello che fa felice un programmatore. Se poi si aggiunge un lunedì festivo che va innanzi e indietro nel calendario a seconda (letteralmente) di come gli gira la luna, abbiamo completato il teatrino.

    Nonostante i linguaggi attuali abbiano ricche funzioni di libreria per limitare i danni di questo metodo di computo del tempo figlio di tradizioni antiche mai cambiate, c’è ancora qualcuno che ne cade vittima:

    Come tutti sappiamo che 19 Zellini fanno una Falce e che 17 Falci fanno un Galeone, sappiamo anche che 24 ore fanno un giorno, quindi il conto alla rovescia di cui sopra dovrebbe essere scritto (magari con un font più leggibile) -5g 3h eccetera.

    (altro…)

  • SHA-3

    Il NIST ha scelto l’algoritmo da utilizzare per la funzione hash SHA-3: la funzione Keccak (pron. [kɛtʃak] come ketchup) ideata da Guido Bertoni, Joan Daemen, Michaël Peeters e Gilles Van Assche.

    Gli algoritmi di hash sono molto utili nell’informatica e nella crittografia.

    In informatica si possono usare per confrontare più velocemente stringhe più lunghe: se voglio, ad esempio, individuare tutti i file uguali tra loro su un disco mi conviene creare un hash associato ad ogni file (con il suo path), metterli in ordine e verificare i doppi. Questo permette di elaborare delle stringhe di pochi byte anziché file considerevolmente più grossi.

    (altro…)
  • La sicurezza dei database è in mano agli sviluppatori

    Agli sviluppatori delle applicazioni che usano i database, ovviamente.

    Dark Reading raccoglie in un articolo un decalogo di consigli per gli sviluppatori che vogliono mitigare i problemi di sicurezza delle applicazioni che utilizzano database (tipicamente SQL, ma non necessariamente).

    Alcune norme sono ovvie e ne abbiamo parlato anche noi: la prima in assoluto è la SQL injection, molto più diffusa di quello che si possa credere. Basta, infatti, che un solo campo di un’intera applicazione non venga opportunamente sanificato per mettere a repentaglio la sicurezza dell’intero progetto.

    (altro…)
  • Fammi eseguire il dannato script!

    Chi si è avvicinato all’utilizzo della PowerShell ha cozzato quasi subito con la bella feature che impedisce di eseguire gli script.

    Sembra una barzelletta, ma l’interprete di script di Microsoft per default non esegue gli script non firmati. Nulla di grave perché un Set-Execution-Policy Unrestricted rimette le cose a posto.

    Nonostante ciò, oggi non riuscivo ad eseguire uno script che avevo caricato su un server di un cliente nonostante la policy Unrestricted confermata anche da Get-Execution-Policy.

    Il problema era che avevo scaricato da Internet lo script: l’avevo creato a casa mia, l’avevo compresso e caricato su uno dei miei server e da lì l’avevo scaricato sul computer a cui ero connesso in VPN.

    Tanto è bastato per far arrabbiare PowerShell.

    (altro…)

  • Reset della password

    Per vari motivi ho cercato in giro alcune linee guida su come scrivere una buona procedura di reset della password di un account via posta elettronica, ne riassumo qui alcune, in ordine sparso.

    Non modificare i dati fino alla conferma dell’utente. A meno di necessità specifiche o casi particolari, i dati di autenticazione non devono essere modificati fino all’avvenuta conferma da parte dell’utente, al fine di impedire che buontemponi blocchino l’accesso all’utente semplicemente chiedendo un reset della password.

    Usare CAPTCHA. La pagina di richiesta del reset della password dovrebbe contenere un CAPTCHA per evitare che i sistemi automatici possano attaccare facilmente il sistema oppure possano provocare disagi a più utenti.

    Utilizzare una buona fonte di entropia. L’URL per il reset della password inviato via mail deve contenere una parte casuale, che non deve essere legata al timestamp o ad altri valori deterministici. È bene utilizzare sempre il generatore di numeri casuali disponibile sul sistema (/dev/urandom per *NIX) anziché una funzione di libreria del linguaggio.

    Limite di tempo. L’URL utilizzabile per il reset della password deve avere una scadenza oltre la quale non è più valido.

    Spiegare bene. Sia la pagina di reset della password sia le mail che vengono inviare all’utente devono essere ben chiare e spiegare bene la modalità di reset. In particolare, la mail deve indicare in maniera precisa il nome del sito di cui si sta reimpostando la password, il termine ultimo di validità e le azioni da intraprendere se chi riceve la mail non ha chiesto il reset della password.

    Confermare. Una volta terminata (o cancellata) l’operazione, è bene inviare una seconda mail di conferma all’utente.

    Monitorare. Una funziona amministrativa dovrebbe segnalare gli account di cui viene richiesta spesso la reimpostazione della password. Inoltre è bene impedire un numero non-umano di richieste di reset della password nell’unità di tempo, come, ad esempio, 500 richieste all’ora.

    HTTPS. Se possibile, utilizzare HTTPS con un certificato valido per il form di richiesta di reset e per l’URL di sblocco.

    Cookie. Non devono essere utilizzati i cookie per identificare l’utente ed eventuali cookie di sessione o di identificazione devono essere cancellati nel momento in cui la password viene reimpostata.

    Riservatezza. Se nel form di richiesta password si richiede direttamente la mail (da evitare, se possibile), quando viene inserita una mail sconosciuta, il programma deve comportarsi allo stesso modo in cui si comporterebbe se la mail fosse di un utente registrato, al fine di impedire ad un eventuale curioso o attaccante di capire se una mail corrisponde ad utente effettivamente registrato.

    Va da sé che queste sono linee guida che si applicano a siti normali, per ambienti che richiedono una sicurezza maggiore devono essere messe in campo procedure completamente diverse.

  • Buco di sicurezza in MySQL/MariaDB

    È stato scoperto un pericoloso baco in MySQL/MariaDB che potrebbe permettere l’accesso come root ad un database server.

    La vulnerabilità non funziona su tutte le installazioni di MySQL (inclusa CentOS) e dipende da come è stato compilato il server.

    Il problema risiede nella routine di autenticazione di un utente. Quando viene aperta una connessione a MySQL/MariaDB viene generato un token calcolando un SHA della password fornita e di una stringa casuale; il token viene quindi confrontato con l’SHA calcolato con il valore corretto. Per un errore di cast potrebbe succedere che le due stringhe vengano considerate uguali anche se non lo sono e anche se memcmp() ritorna un valore diverso da zero; se si verifica questo caso, MySQL/MariaDB pensa che la password sia corretta e permette l’accesso. La probabilità che questo accada è di 1/256.

    (altro…)

  • Perché ieri siamo andati down

    Ieri il sito non è stato disponibile per metà della giornata.

    Alle 11:54 CET il MySQL ha dato forfait probabilmente a causa di un guasto hardware. La macchina è morta lentamente (Linux è duro da ammazzare). Stando ai log, il server si è riavviato autonomamente almeno tre volte durante il pomeriggio.

    Il titolare della macchina, che gentilmente offre l’ospitazione a Siamo geek, ha aperto tre ticket presso il fornitore, Keyweb, ma non ha ottenuto risposta.

    Verso le 22:00 ho provato io ad aprire un quarto ticket e sono stato più fortunato: un tecnico è intervenuto e dopo una mezz’oretta il server era di nuovo online.

    (altro…)
  • Trentennale del Sinclair ZX Spectrum

    Il 23 aprile 1982 veniva lanciato un computer storico: lo ZX Spectrum della Sinclair.

    (altro…)

  • La trappola bisestile

    Il sistema attuale del computo del tempo è frutto della stratificazione di usanze e adattamenti che affondano le loro radici oltre 2.000 anni or sono.

    Con l’avvento del calcolo automatico questo sistema ogni tanto gioca brutti scherzi, l’ultimo ha visto come vittima Windows Azure.

    In un dettagliato e interessante rapporto che merita di essere letto anche se non interessati ad Azure, Bill Laing spiega dove sono iniziati i guai.

    Uno degli agent del servizio crea dei certificati con un anno di validità, purtroppo la scadenza viene calcolata aggiungendo un’unità all’anno, nella presunzione che, se giorno e mese esistono quest’anno, esisteranno anche l’anno prossimo.

    Presunzione sempre valida, tranne che per un giorno ogni 4 anni.

    Chi ha in giro sistemi che calcolano le date di scadenza (o similari) usando l’algoritmo sopra descritto dovrebbe controllare se non sono state scritte o calcolate date inesistenti.

    Il prossimo appuntamento è per il secondo intercalare di fine giugno.

  • Goofile

    Goofile è una piccola utility a riga di comando (niente interfaccia touch, sorry) di Thomas (G13) Richards che produce un elenco di file di un certo tipo indicizzati da Google in un determinato nome a dominio.

    L’utilizzo è assolutamente semplice perché l’utility ha bisogno di soli due parametri:

    ./goofile.py -d siamogeek.com -f pdf

    Questo comando elenca tutti i file PDF indicizzati da Google nel nome a dominio di questo blog.

    Di per se non c’è nulla di particolare, dal momento che un elenco simile può essere ottenuto utilizzando i parametri noti di Google. La parte utile di Goofile è che può essere utilizzato in uno script per elaborare i suoi risultati. (via Darknet)

  • SQL injection

    Questo articolo è per chi non sa cosa sia la SQL injection.

    Con questo termine si identifica una classe di vulnerabilità dei software che consente ad un utente qualsiasi di aggirare i controlli del software e inviare direttamente al server comandi SQL.

    Prima della diffusione dei server SQL i dati venivano archiviati e recuperati utilizzando funzioni di libreria del linguaggio di programmazione. Esisteva un comando/funzione del linguaggio per aprire un archivio di dati, uno per cercare un record, un altro per aggiornare i dati, un altro ancora per cancellarli e così via. Con questo sistema era di fatto impossibile portare attacchi tipo SQL injection perché i comandi relativi al trattamento dei dati erano parte del programma. In altre parole, le azioni che avevano come oggetto i dati erano cablate nel programma e non c’era modo di cambiarle se non cambiando il programma (e ricompilarlo).

    La diffusione capillare dei server SQL ha cambiato le carte in tavola.

    (altro…)
  • Client TCP o UDP con bash

            exec {fd}<>"/dev/tcp/siamogeek.com/http"
            # scrittura nel socket
            printf "GET / HTTP/1.0\r\n" >&$fd
            printf "\r\n" >&$fd
            # lettura "until EOF" dal socket
            cat &-

    Questo breve script per bash permette di scrivere e leggere dei dati da un socket TCP o UDP senza dipendere dalla presenza di altri programmi.

    Il tipo di protocollo, l’host e la porta sono specificati nella prima riga dello script; {fd} serve per dire a bash di aprire il primo file descriptor disponibile.

    La parte di scrittura è conforme allo standard http e deve essere modificata secondo le necessità. (via behind the wall…)