SIAMO GEEK

Tag: database

  • Il formato DBF

    Chi vi scrive ha mosso i primi passi nel mondo dei database con dBase II su CP/M, ha passato gran parte del servizio di leva davanti ad un M24 con dBase III+, si è guadagnato da vivere per un po’ di anni scrivendo applicazioni in Clipper.

    Quindi, il DBF è stato mio compagno di viaggio informatico per qualche tempo, qui trovate una bellissima e molto documentata storia di quel formato e dell’ecosistema che ha generato da quando è nato ai giorni nostri: The Rise, Fall, and Surprising Survival of dBase.

  • Hash table

    Un video molto istruttivo in un ottimo inglese che spiega molto bene l’utilizzo delle funzioni di hash applicate all’indicizzazione dei database.

    Anche se sapete come funzionano e cosa sono le funzioni di hash, consiglio di vedere questo video perché è molto interessante.

  • …e poi hai vinto

    SQL-Loves-Linux_2_Twitter-002-640x358Premessa: non sono aprioristicamente tifoso di nessun sistema operativo o linguaggio. Per me ci sono due tipi di sistemi o linguaggi: quelli adatti ad uno scopo e quelli non adatti.

    Microsoft ha annunciato che a metà 2017 potrebbe uscire una versione per Linux del loro SQL Server.

    Ricordo ancora quando nel 2001 Steve “Developers! Developers! Developers!” Ballmer aveva detto «Linux is a cancer that attaches itself in an intellectual property sense to everything it touches» (altro…)

  • Violati siti collegati alla Polizia e alla Giustizia

    hack giustiziaSu un blog riconducibile ad Anonymous è apparso un post intitolato Summum ius, summa iniuria nel cui testo, riprodotto a fianco, ci sono i link per scaricare i dump dei database di alcuni siti collegati alle forze dell’ordine o alla Giustizia.

    Ho dato un’occhiata veloce ai file prima di distruggerli e il risultato è a dir poco sconsolante: ancora una volta ci troviamo davanti ad una leggerezza nella gestione dei dati che non dovrebbe esistere in certi settori, specie quelli incaricati di far rispettare la Legge. (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…)

  • Ridondanza delle informazioni

    Non esiste organizzazione in cui ogni informazione è registrata una volta sola e pretendere di arrivare a questo utopico obbiettivo è irrealistico e, spesso, improduttivo.

    Però alcune volte le informazioni sono ridondate in maniera non necessaria, con rischi di costi nascosti dovuti alla manutenzione di più archivi e alle conseguenze del disallineamento degli stessi (o l’allineamento è fatto per via algoritmica o non è). In questo scenario si inserisce spesso un irrazionale antagonismo tra uffici (o tra scrivanie dello stesso ufficio) tale per cui un’informazione come un numero di telefono di un cliente diventa un dato custodito più gelosamente del PIN del bancomat.

    (altro…)

  • 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…)