Se il tuo modello di attacco consente a "autori di attacchi di caricare i propri script", hanno accesso a tutto ciò che lo stesso script può vedere o fare e "accesso sicuro al database", per questo valore di sicuro , è semplicemente non possibile .
(A meno di ridisegnare il database in modo che possa eseguire un controllo su tutti i file PHP coinvolti in una determinata connessione - mentre teoricamente possibile, sarebbe estremamente difficile - basta pensare a cosa significa identificare gli script PHP, incluso da un Web processo , che ha aperto una connessione, di cui il server DB conosce solo l'origine indirizzo e porta ! - e molto probabilmente un killer delle prestazioni)
Ma a questo punto puoi allontanare una certa logica dal server web, considerata inaffidabile, e vedere quale sicurezza può essere trovata altrove.
Ad esempio, puoi fare in modo che i diversi livelli di accesso alle applicazioni Web utilizzino credenziali diverse: potresti avere tre utenti del database "ospite", "utente" e "admin". Puoi organizzare le cose in modo che, ad esempio, l'amministrazione degli utenti da parte dell'utente admin non venga eseguita sullo stesso server web (puoi separarla per utente del processo, su un altro webroot, un'altra VM o un server Web separato fisicamente).
La maggior parte delle funzioni e delle query che è possibile replicare utilizzando procedure e funzioni con privilegi elevati che possono accedere ai dati sottostanti a cui gli utenti Web non hanno accesso : ad esempio è possibile eseguire i controlli di accesso con una funzione:
DELIMITER //
CREATE FUNCTION is_valid_user(user varchar(32), pass varchar(32))
returns BOOLEAN
DETERMINISTIC SQL SECURITY DEFINER
BEGIN
DECLARE ret BOOLEAN;
SELECT 1 = COUNT(*) INTO ret FROM users WHERE user = username AND MD5(pass) = password;
RETURN ret;
END//
DELIMITER ;
L'applicazione Web come utente web ha EXECUTE privilege, ma non ha SELECT/INSERT/DELETE privilegi sulla tabella users . Quindi non può enumerare gli utenti, o resettare tutte le password in un colpo solo,
È anche possibile (ma non molto utile, dal momento che la possibilità di caricare script eseguibili rende uno scenario quasi maniaco ideale) per utilizzare l'account guest per recuperare web credenziali di accesso, memorizzate nella tabella users , a condizione che l'utente Web abbia la password corretta:
- utente Giovanni si collega con la password "Doe". L'applicazione Web è in esecuzione come guest
- la funzione
get_credentials('John','Doe') restituisce 'web: myfirstpass'
- L'applicazione Web cambia le credenziali in web e ora ha accesso a più funzioni
Tutta la registrazione dei dati è solo INSERT (solo l'amministratore può cancellare i record di log) e l'accesso a dati importanti / "finanziari" (ad esempio una tabella invoice ) può essere eseguito eseguendo tutte le operazioni su una tabella temporanea di proprietà da web , mentre una procedura privilegiata può essere utilizzata per finalizzare e convalidare la tabella e copiarla in invoices .
Con un po 'più di lavoro, l'utente può essere associato a una stringa "identificatore di sicurezza" altamente casuale che è unica per lui. Solo fornendo tale identificatore di sicurezza è possibile accedere alle procedure che recuperano le fatture; e tali procedure selezioneranno solo le fatture con lo stesso identificatore.
In questo modo - un modo molto laborioso, ammettiamolo - un utente malintenzionato può accedere solo ai dati degli utenti che accedono e vengono ingannati dalle proprie credenziali sul server Web compromesso.
Ti rimane il problema di reagire rapidamente a tale compromesso.
Su un server Linux con inotify , sarebbe possibile per monitorare continuamente i file e rimuovere quelli che non sono "approvati" (cioè il loro hash SHA1 non è nella lista "consentita"). Qualsiasi modifica o aggiunta ai file monitorati determinerebbe la loro rimozione e un avviso inviato all'amministratore:
inotify: '/srv/www/padma/htdocs/ CREATE dfqjkw.php'
inotify: '/srv/www/padma/htdocs/ MODIFY dfqjkw.php'
inotify: '/srv/www/padma/htdocs/ CLOSE_WRITE,CLOSE dfqjkw.php'
ANOMALY: '/srv/www/padma/htdocs/dfqjkw.php' (SHA: e0a6bf9020320dca178cf115da4fa26de0278a25cf41702d667988877cdbc2d1) is neither known nor in testing
inotify: '/srv/www/padma/htdocs/ DELETE dfqjkw.php'
ACTIONS: '/srv/www/padma/htdocs/dfqjkw.php' targzipped, sent to root, and removed
Ciò richiederebbe anche un po 'di tweaking per le persone che caricano i loro siti web - avresti bisogno di un sito Web FTP "test" dove avviene il caricamento e una procedura di "approvazione" mediante la quale viene estratta la firma di ogni file il sito web viene copiato sul filesystem "di produzione", raddoppiando efficacemente l'utilizzo dei dati.
D'altro canto, il furto di credenziali FTP come molti trojan non sarebbe più utile: in assenza della procedura di approvazione, i file compromessi sarebbero presenti solo su link , che sarebbe accessibile solo da alcune reti selezionate, non dal link che è consentito a tutti.