Protezione di uno script per impedire l'esposizione del database

3

Abbiamo uno script con codifica Ioncube in esecuzione su un server Web Apache che memorizza le informazioni riservate dei clienti in un database MySQL. Abbiamo configurato lo script per l'esecuzione con il proprio account utilizzando suphp. Come al solito lo script legge le credenziali del database da un file 'config.php'. Vorremmo mitigare il rischio che i contenuti del database vengano esposti tramite un exploit zero day. Il sistema operativo del server web, Apache e MySQL sono stati rafforzati. C'è qualcosa che possiamo fare per bloccare ulteriormente questo script. Ad esempio, se qualcuno ha sfruttato lo script, presumo che finirebbe con gli stessi privilegi dell'account suphp in cui viene eseguito lo script: tenterebbero di mysqldump il database? Dovremmo limitare l'accesso a tutti i binari di mysql?

    
posta Michelle 30.05.2012 - 01:01
fonte

2 risposte

2

Non hai menzionato attacchi MYSQL injection nel tuo elenco di precauzioni. Inoltre è possibile ridurre le autorizzazioni dell'utente mysql per il database. Di solito le persone danno all'utente tutti i diritti, ma puoi limitare la capacità dell'utente di mysql di fare ALTER, CREARE, CREARE ROUTINE, CREARE TABELLE TEMPORANEE, CREARE VISTA, CANCELLARE, GOCCIA, ESEGUI, INDICE, INSERISCI, TABELLE DI BLOCCO, REFERENZE, SELEZIONA, VISUALIZZA VISUALIZZA , TRIGGER e UPDATE. Fornisci l'autorizzazione utente mysql necessaria per eseguire lo script.

    
risposta data 30.05.2012 - 10:21
fonte
0

Un approccio difensivo è di pianificare il fallimento e limitare i privilegi che si danno alla vostra applicazione e al vostro amministratori.

Detto questo, gli script protetti da Ioncube sono uno scherzo, tutta l'offuscazione del codice è molto facile da minare in PHP usando runkit . Se ti affidi a questo come mezzo per proteggere un qualche tipo di password, allora hai un problema molto serio nelle tue mani. Non è richiesto uno 0 giorni perché non stai facendo nulla per proteggere i tuoi segreti.

Questo mi ricorda molto del trucco Super Meat Boy MySQL , lo sviluppatore aveva un'applicazione desktop che si collegava direttamente a un server MySQL. Inutile dire che lo sviluppatore è stato violato alle lacrime .

Nessuna quantità di crittografia può risolvere questo problema. Non è mai accettabile consentire a un utente malintenzionato di connettersi al proprio database. È necessario implementare un'API che limiti l'accesso accessibile al client.

    
risposta data 30.05.2012 - 02:49
fonte

Leggi altre domande sui tag