Vedo sistemi che usano i prefissi del database. Alcuni lo chiamano una funzione di sicurezza. Alcuni lo chiamano un modo per avere più installazioni in un database.
Il principale pro è che è più difficile indovinare l'intero nome del tavolo. D'altra parte, se hai qualche tipo di accesso al database, direi che potresti capire lo schema / l'elenco delle tabelle.
È una funzionalità di sicurezza valida?
Questa è sicurezza attraverso l'oscurità . Anche se potrebbe non ferirti in tutti i casi, da solo non fornisce sicurezza. Non fare affidamento su questo come protezione.
Breve parabola
Supponiamo che tu mantenga i tuoi soldi in un barattolo con l'etichetta MONEY nella tua casa. Poiché sai che a volte dimentichi di chiudere a chiave la porta quando esci di casa, puoi ricollocare il barattolo COOKIES per impedire a un ladro di trovarlo. Ti sentiresti più sicuro ora? Certo, un ladro molto pigro e sciocco potrebbe non vederlo, ma non dovresti essere un ladro professionista per rubare i tuoi soldi. Non sarebbe meglio semplicemente ricordare di chiudere la porta invece?
Ritorno al mondo dei computer
Supponiamo che tu abbia una vecchia installazione di phpBB con una vulnerabilità di SQL injection. Di default le tabelle sono precedute da phpbb_ . Lo cambi in obscure_ . Questo ti aiuterà?
Una scansione ingenua potrebbe non riuscire a trovare nomi di tabelle con codice fisso (come phpbb_users con tutte le password), e quindi fallire. Ma anche uno script kiddie può eseguire uno script che esegue SHOW TABLES e trova obscure_users . Infatti, ci sono strumenti che scaricheranno automaticamente il contenuto di tutte le tue tabelle attraverso una vulnerabilità di SQL injection.
Conclusione
Quindi qual è la lezione qui? Mentre cambiare prefissi di tabella (rietichettatura il vaso) potrebbe forse proteggere l'utente da l'attacco più semplice muto automatizzato (lo stupido, ladro pigro), si sarebbe ancora vulnerabili a semplici attacchi eseguiti da script kiddies (un ladro ricerca attraverso i vostri vasetti). Quando si ha una vera vulnerabilità come l'iniezione SQL, la soluzione è quella di correggere quella vulnerabilità (bloccare la porta), e non aggiungere un sottile velo di oscurità.
Detto questo, una semplice precauzione che potrebbe rallentare alcuni attacchi potrebbe ancora valere la pena di "difesa in profondità" se non ha effetti collaterali dannosi. Non sentirti al sicuro solo perché lo implementa.
(Come appendice, dovrei dire che l'esecuzione di più installazioni nello stesso database potrebbe avere implicazioni sulla sicurezza a seconda della situazione.)
No, è olio di serpente.
Quando qualcuno trova una vulnerabilità di SQL injection in un'applicazione, non sapere i nomi delle tabelle è solo un ostacolo molto secondario. Molti payload di iniezione di titoli (come la buona vecchia password universale ' OR '1' = '1 ) non hanno nemmeno bisogno di conoscere alcun nome di tabella. E se l'utente malintenzionato scopre un modo per scaricare dati da tabelle arbitrarie, deve semplicemente scaricare la tabella di sistema INFORMATION_SCHEMA.TABLES (o equivalente, a seconda del sistema di database utilizzato) e ottiene i nomi di tutte le altre tabelle.
Tuttavia, non è necessariamente l'olio di serpente tossico . Essere in grado di condividere più installazioni con lo stesso database può essere una caratteristica legittima (come su un hoster Web a basso budget che consente solo di utilizzare un singolo database sul proprio cluster MySQL) e finché si ha un casuale prefisso e i nomi delle tabelle sono ancora leggibili, non influisce molto sulla manutenzione. Ma non aggiunge molta sicurezza.
Nei sistemi basati su DBMS ampiamente utilizzati come WordPress, è prassi comune configurare un'istanza per utilizzare nomi di tabelle come my_fav_prefix_posts al posto di wp_posts .
Perché? Presumibilmente rallenta gli script kiddies.
Alcuni anni fa ci fu una serie di attacchi di massa su istanze di WordPress. I cybercriminali poco sofisticati (script kiddies) hanno utilizzato software di attacco non sofisticati (script) per contattare un numero elevato di server in cerca di vulnerabilità. Quando gli script non hanno trovato la tabella wp_posts , sono passati al server successivo nella loro lista di attacco. Naturalmente, un paio di settimane più tardi le sceneggiature sono diventate un po 'più sofisticate e le istanze di WordPress non potevano più nascondere i loro tavoli in bella vista.
Suppongo che sia l'origine del mito che i prefissi di database alternativi danno un ulteriore livello di sicurezza. Non lo fanno.
Direi che questo non aggiunge nulla alla sicurezza. Ma se non puoi (o non vuoi) fare affidamento su schemi per separare le tue tabelle tra diverse applicazioni, l'uso di prefissi diversi consente a diverse applicazioni di condividere lo stesso database senza il rischio di conflitti.
Ma non aggiunge sicurezza reale.
Leggi altre domande sui tag databases