Sicurezza dell'applicazione Web PHP [chiusa]

Se un utente malintenzionato ha accesso solo al database "live" (più comunemente tramite SQL injection), quindi la crittografia dei campi utilizzando un segreto non archiviato nel database è sufficiente - anche qualche chiave segreta hard-coded nel codice dell'applicazione o file di configurazione. Non è necessario utilizzare le chiavi per client.

Se sei preoccupato che un utente malintenzionato possa in qualche modo accedere ai dati nella tua web root, ma non al resto del file system (in genere se il tuo server non è configurato correttamente per consentire la navigazione nel suo contenuto Web), non cambia nulla - dopotutto, il tuo server il codice o il file di configurazione dovrebbero trovarsi al di fuori della web root, giusto? (Ho poca esperienza con PHP, quindi potrei sbagliarmi)

Se la tua preoccupazione è che un utente malintenzionato si impadronisca dell'intero filesystem, devi assicurarti che la chiave esista solo nella RAM. Un modo per farlo sarebbe richiedere l'inserimento di una password all'avvio (re) del server e il mantenimento della chiave derivata in una variabile accessibile a livello globale (ancora una volta, non so se è possibile con PHP). Potrebbero esserci altre opzioni, ma qualsiasi cosa io possa pensare potrebbe introdurre altri punti di errore. [1]

I was thinking of generating the certificates on registration and use part of the footprint of a certificate to encrypt the user's data. so the SHA1 or MD5 footprint could do as key and IV.

L'utilizzo di qualsiasi cosa dal certificato è una cattiva idea, poiché i certificati sono per definizione public (le parti private non abbandonano mai la macchina dell'utente). Se in qualche modo potresti decodificare alcuni dati usando la sua chiave privata (qualcosa che AFAIK non è ampiamente supportato in questo momento, ma potrebbe essere in futuro ), lato client, quindi potresti essere all'altezza di qualcosa ... Ma come stanno le cose ora, potresti semplicemente creare una chiave casuale per ogni utente e avere il tuo codice applicazione leggerlo (da un luogo sicuro) e applicarlo ai dati dell'utente prima di inserirli / emetterli.

Questo, ovviamente, presuppone che sia necessario isolare i dati di un utente dagli altri utenti. Se questo non è il caso, una singola chiave globale potrebbe essere sufficiente, come descritto nella prima parte di questa risposta.

(un'ultima nota: non hai menzionato il metodo che intendi utilizzare per crittografare i dati. Se utilizzi una codifica di streaming, ad esempio, avere una singola IV per ciascun utente non è sufficiente - devi avere uno diverso per ogni dato che si desidera proteggere. Non importa però come li memorizzi, dal momento che non dovrebbero essere riservati, solo unici . Ci sono modi per creare una singola IV utilizzabile per crittografare un sacco di dati , ma questo è al di là delle mie attuali conoscenze, quindi non farò un'opinione su di loro.)

[1]: solo per citarne uno, è possibile ricavare una chiave di crittografia dalla password dell'utente, memorizzarla in un cookie di sessione (sicuro) e passarla avanti e indietro dal server al client. Dal momento che non è memorizzato da nessuna parte, un utente malintenzionato non potrà accedervi anche se ha ottenuto l'accesso all'intero server (presupponendo ovviamente il tuo sito correttamente password salts and hashes e la chiave di autenticazione e la chiave di crittografia sono indipendenti l'uno dall'altro ) . Per alcuni approfondimenti sulla difesa, potresti persino combinare quella chiave con una memorizzata solo nel server. Lo svantaggio evidente è che parte della sicurezza del sistema dipende ora dal browser dell'utente e anche dal modo in cui i cookie di sessione vengono gestiti sia nel server che nel client.

Sembra che tu abbia un malinteso fondamentale riguardo alla scrittura di software sicuro e probabilmente non dovresti tentare di farcela con il tuo attuale livello di comprensione. I certificati SSL non ti aiuteranno affatto a proteggere l'accesso ai DB o il contenuto del DB. La gente non sarà quasi certamente in grado di raggiungere i certs, ma non fa nulla per proteggerti.

Per proteggere un DB, è necessario filtrare l'input per prevenire l'SQL injection, rafforzare il server stesso e, se necessario, proteggere i dati a riposo, utilizzare la crittografia, che richiede solo chiavi che possono essere crittografate con chiavi derivate da password e memorizzate in il database stesso.

Are there any chances that an attacker who gains access to the application, by exploit or any other method, would be able to get access to the certs if they did not previously know about them?

Sì, non solo è possibile, è probabile. Qualsiasi file a cui l'applicazione ha accesso, chiunque si occupi della tua applicazione avrà anche l'accesso. In genere sarà in grado di visualizzare elenchi di directory, eseguire programmi e fare qualsiasi cosa un normale utente possa fare.