Rischi per la sicurezza che utilizzano tmpfile () per dati sensibili in PHP

1. Si presume che i dati vengano scaricati quando vengono scritti su un file. In teoria potrebbe rimanere nei buffer e non essere mai scaricato, ma non puoi fare affidamento su questo e non hai modo di sapere se lo ha fatto. Il percorso del file temporaneo potrebbe essere un disco montato su RAM (come tmpfs in Linux), ma probabilmente non hai accesso a tale informazione e, ancora una volta, non puoi fare affidamento su quello che è il caso. Lo scenario peggiore (e più probabile) è che sia scritto sul disco rigido, nel qual caso chiunque con privilegi di lettura del disco non elaborato, come l'amministratore, potrebbe quindi cercare tra i settori grezzi del disco rigido ed esaminare i dati. Non è così difficile come sembra, ho recuperato i file di testo cancellati prima di utilizzare un semplice concatenamento degli strumenti NIX dd e grep .

2. Non penso che sia un problema. Il file creato da tmpfile() deve essere eliminato automaticamente quando si chiude il file, indipendentemente da dove è stato creato. (Almeno, così dice il manuale e l'esperienza.)

3. Certo. L'amministratore può monitorare la directory temporanea e fare una copia di qualsiasi file che vede creato. Questo dovrebbe essere fattibile a livello di modalità utente, ed è certamente fattibile a livello di driver (se hanno scritto un driver di furto di file e inserito nello stack del filesystem) se sono molto dediti allo scorrimento di tutti i file temporanei.

Come regola generale, tutti i dati che devono essere crittografati non devono essere scritti in un file non crittografato. I contenuti dei file non sono sotto il tuo controllo diretto e i dati non crittografati devono essere.

La crittografia dovrebbe essere possibile al volo con schemi di crittografia standard. Potrebbe essere un po 'più complicato di una semplice chiamata di crittografia, ma dovrebbe essere sicuramente possibile utilizzando qualsiasi libreria di crittografia competente.

L'amministratore può fare qualsiasi cosa . Se l'amministratore è il tuo nemico, allora hai perso. Può copiare i tuoi file preziosi indipendentemente da dove li metti; può anche solo leggere i contenuti della RAM del tuo processo PHP direttamente.

Se l'amministratore è tuo amico, i tuoi prossimi nemici sono altre persone che hanno una qualche forma di accesso alla stessa macchina, ad es. utenti normali (non amministratori) della macchina e / o altri script PHP in esecuzione sullo stesso server. Il tmpfile di PHP si basa (almeno sui sistemi Unix-like) sulla funzione tmpfile() fornita dal sistema operativo (in realtà una funzione di libc). Se usi Linux, sei fortunato: che l'implementazione specifica crea il file con un nome casuale in /tmp e lo elimina immediatamente . Come per semantica Unix, il file esiste ancora (ci vuole un po 'di spazio nel filesystem) ma il nome viene distrutto, impedendo qualsiasi accesso da parte di altri utenti.

Potresti avere ancora paura degli altri script PHP, se questi sono ostili e il motore PHP non è adeguatamente vincolato, perché questi script vengono eseguiti con lo stesso account del tuo (l'account a livello di sistema operativo, ovvero l'utente Unix che esegue il server Web) e quindi può accedere al file da un collegamento in /proc . Ma è piuttosto estremo; se persone distinte, potenzialmente ostili tra loro, possono aggiungere i propri script PHP allo stesso server senza isolamento tra loro, quindi c'è qualcosa di molto sbagliato nella struttura del server e l'amministratore non sta facendo il suo lavoro.

1. Poiché un file temporaneo è uguale a un file normale (nello stesso modo in cui è scritto sul disco, anche se solo per un breve periodo), potrebbe ancora essere ripristinato utilizzando uno strumento di recupero dati finché non viene sovrascritto. Per quanto ne so quando viene rimosso il file temporaneo è solo "scollegato" e non cancellato in modo sicuro
2. La cartella temp è impostata a livello di sistema operativo, quindi in teoria potrebbero cambiare la posizione, ma dovrebbe essere rimossa al termine dell'esecuzione degli script indipendentemente dalla cartella
3. Poiché il file esiste per l'intera durata dello script (o fino a quando non viene chiuso esplicitamente), è possibile che possano guardare la directory e copiare tutto ciò che appare in essa. Il file dovrebbe avere il proprietario impostato su chiunque lo crei, ma poiché l'amministratore avrà root, avrà comunque accesso

Per indirizzare il punto 1, puoi chiamare srm sul file ed eliminarlo esplicitamente te stesso, che dovrebbe impedirne il recupero. Per quanto riguarda i punti 2 e 3, è fuori mano a meno che tu stesso non possa proteggere il server.

Spero che questo aiuti