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.

Il secondo errore più comune commesso dagli sviluppatori è l’eccesso di informazioni di errore visualizzate all’utente. Ci dicono che non dobbiamo essere criptici nella messaggistica, però è anche bene evitare di esagerare per non rivelare involontariamente dati che potrebbero essere utili per un attacco mirato.

Un altro errore molto comune è l’abitudine di far collegare l’applicazione al database utilizzando privilegi elevati (super, sa, root…). Questa pessima abitudine è molto più comune negli applicativi commerciali (ad esempio i gestionali), che negli applicativi web. Questo perché, di solito, l’applicativo web viene installato in un contesto in cui la password di root del database non è disponibile, mentre il database server di un applicativo commerciale viene spesso installato dallo stesso fornitore con la presunzione di essere sempre l’unico ad usare un database su un host.

Non immaginate quanti database MSSQL di applicazioni commerciali vengono installati con sa senza password o con password sa.

L’articolo cita altri esempi, che valgono la pena di essere letti per verificare se, per le cause più diverse, abbiamo in giro applicazioni vulnerabili. (via Jennifer Manguino)