Uno dei consigli più comuni in merito alla protezione di WordPress , Magento , e altri software ampiamente usati è quello di aggiungere un prefisso ai nomi delle tabelle del database o modificare il prefisso predefinito. Ad esempio, si sente spesso cambiare il prefisso wp_ predefinito per WordPress in qualcosa di oscuro, come 1sdf34jSqo8_ .
La domanda che ho è questa: Questo non è altro che sicurezza per oscurità? E se sì, è una buona pratica farlo comunque?
I pro e i contro che vedo sono:
Vantaggi:
- Molti attacchi di SQL injection hanno necessariamente due passaggi: identificare le tabelle e poi fare qualcos'altro. Ciò non impedisce attacchi come l'invio di una password come
xyz' OR 1=1 --', ma impedisce, ad esempio, una query comeDROP TABLE foodi fare effettivamente qualsiasi cosa, finché l'attaccante non apprende in qualche modo il nome della tabella. - Aiuta a mitigare l'attacco da incubo zero-day in cui esiste realmente una vulnerabilità SQLi. Un po 'di oscurità è utile in quelle situazioni.
- Potrebbe rendere un po 'più facile intercettare e bloccare determinati attacchi tramite mod_security o un WAF. Ad esempio, se il mio prefisso di tabella è
1sdf34jSqo8_e quella stringa viene visualizzata nei dati GET o POST, ho intenzione di essere molto sospetto di tale richiesta. Ma poi, se l'attaccante ha quella stringa, probabilmente sono già in pegno. Vedere che il testo di chiunque non sia già autenticato come superutente è in realtà probabilmente un avviso diretto per il cercapersone, infatti. - Abilita l'installazione di più copie di un'applicazione in un database, per quelle istanze in cui un host o un fornitore di servizi consente di avere 1 o 2 database ma non limita il numero di tabelle (che non ha mai avuto senso per me , ma sto divagando). * Questa non è una preoccupazione per la sicurezza, è vero, ma è uno dei motivi principali per cui le persone abilitano il prefisso in questo modo.
Svantaggi:
- Questo è un dolore enorme da implementare come sviluppatore. Significa che ogni riferimento di tabella nel tuo codice ha bisogno di una costante o di una variabile aggiunta al nome della tabella. SELECTs semplici sono abbastanza cattivi; modifiche dello schema e patch possono diventare veri e propri incubi. Questo anche rompe la capacità di molti IDE di fare cose come il completamento automatico e il controllo ortografico sulle istruzioni SQL.
- Grazie ai suddetti problemi, è probabile che più possa causare bug e possibili vulnerabilità a causa del fatto che una volta qualcuno del team ha scritto una dichiarazione come
SELECT * FROM {prefix}foo LEFT JOIN bar ...e ha dimenticato il prefisso da qualche parte. - Ovviamente è almeno una forma di sicurezza per oscurità. Ciò porta a trascuratezza, eccessiva sicurezza, ecc.
- Non risolve alcun problema che le dichiarazioni preparate e le whitelist non abbiano già risolto.
Penso che la risposta accettata alla domanda "Va bene rivelare i nomi delle tabelle del database?" riassume bene i miei pensieri: non perdi nulla rivelando i nomi delle tabelle se il tuo database è sicuro contro l'iniezione. Se c'è una violazione su un altro livello, come uno script canaglia caricato ed eseguito con successo, quindi (1) il prefisso della tabella sarà facile da scoprire, e (2) ti verrà comunque hosed.
Quindi, la versione breve della domanda: è questo in realtà qualcosa che gli sviluppatori dovrebbero fare durante la creazione di applicazioni, o è solo una cattiva pratica mascherata da ulteriore livello di sicurezza?
EDIT: Per essere chiari, non sto chiedendo se l'utente finale debba andare avanti e cambiare i prefissi per, diciamo, un database di installazione di WordPress. Sto chiedendo se, quando uno sviluppatore sta creando un'applicazione che utilizza un database, lo sviluppatore dovrebbe abilitare questo tipo di funzionalità in primo luogo.