modulo di caricamento PHP sicuro e archiviazione

8

Sto costruendo un'applicazione PHP che consente l'upload di file (.doc / pdf etc) per la revisione da parte di un membro dello staff. Alcuni di questi file saranno alquanto confidenziali, quindi ho bisogno di proteggerli.

Ora la soluzione migliore sarebbe ottenere che il mittente crittografi questi file con GPG o simili prima di caricarli e decrittografarli con una chiave precondivisa all'altra estremità (sul computer dello staff, non sul server Web).

Tuttavia non è realistico aspettarsi che tutti i clienti installino e imparino a utilizzare GPG per caricare i file.

Quindi la soluzione migliore che riesco a trovare è:

1) Carica i file su HTTPS su una pagina protetta da password.

2) Cifra i file utilizzando GPG asimmetrico e un file di chiavi pubblico memorizzato sul server web.

3) Elimina tutte le copie non crittografate del file in / tmp, ecc.

4) Invia un'email per il personale che notifica loro che il file è disponibile per il download.

5) Il membro dello staff accede e scarica il file, quindi elimina la copia crittografata.

6) Il membro dello staff quindi decrittografa il file utilizzando la sua chiave privata che non è archiviata sul server web.

L'idea è che se il server web viene compromesso (è un server dedicato, quindi non condiviso con altri), l'autore dell'attacco non sarà in grado di decodificare questi file perché non troveranno la chiave lì.

Tuttavia: penso che sia ancora vulnerabile.

Perché, se un utente malintenzionato ha root o anche solo il controllo dell'utente del server HTTP, sarà in grado di leggere i dati da / tmp mentre il file viene ancora caricato / crittografato e creare una copia non crittografata che può scaricare in seguito.

Quindi potrei fare tutto questo in memoria senza scrivere in / tmp? Ma c'è ancora il rischio che l'attaccante possa scoprire gli indirizzi di memoria a cui sono scritti i dati caricando un file da soli e quindi utilizzare ptrace per ispezionare e copiare quegli indirizzi di memoria.

Non riesco a pensare a un modo per risolvere questo problema poiché avrò bisogno dei dati in testo in chiaro per fare la crittografia. C'è un modo in PHP per rendere più difficile l'ispezione della memoria? Oppure esiste un servizio web di terze parti che sarebbe meglio usare per questo?

    
posta user350325 25.01.2013 - 22:45
fonte

2 risposte

5

So perhaps I could do all of this in memory without writing to /tmp? But there is still a risk here that the attacker could discover memory addresses that the data is written to by uploading a file themselves and then use ptrace to inspect and copy those memory addresses.

Una configurazione SELinux correttamente installata può mitigare i rischi di una macchina compromessa dal controllo dell'applicazione. In definitiva, devi mantenere il computer sicuro.

I can't think of a way to fix this problem as I will need the data in plaintext in order to do the encryption. Is there a way in PHP to make the memory inspection harder? Or is there a third party web service that would be better to use for this?

Semplicemente non c'è modo di aggirare la realtà di dover avere il file in arrivo in uno stato di cleartext in memoria ad un certo punto del processo di crittografia. Crittografarlo in memoria, tuttavia, è sicuramente la strada da percorrere.

    
risposta data 25.01.2013 - 23:22
fonte
4

È sempre possibile utilizzare JavaScript sul frontend del browser e crittografarlo prima di toccare la rete. Devi comunque utilizzare TLS per trasferire la pagina web, al fine di ridurre le probabilità di un attacco MITM che potrebbe modificare il codice JavaScript.

Alla fine del browser, è possibile generare chiavi AES univoche e quindi crittografare le chiavi AES tramite OpenSSL con la chiave del membro dello staff nel back-end, in modo che il destinatario possa decodificare la chiave simmetrica con la propria.

Potrei inviarti MEGA come riferimento di un esempio di lavoro.

Vantaggi :

  • Usando JavaScript non avrai mai il file decifrato in memoria.
  • Con la crittografia della chiave AES, avrai tempi più veloci.
  • Non hai bisogno del GPG sul lato client.
  • Le chiavi sono monouso, quindi avrebbero bisogno di craccare tante chiavi quanti sono i documenti.

Fai attenzione :

  • Le chiavi devono essere protette: non devono essere scritte nella memoria permanente prima di passarle attraverso la crittografia OpenSSL (e quindi dimenticate).
  • A qualsiasi segno di attacco, la memoria dovrebbe essere una priorità. Per attenuare le chiavi AES One-Use rubate, uccidere il server Web al primo segno e riavviarlo di nuovo. L'utente vedrà solo un po 'di tempo di inattività.
  • trasferimento di JavaScript e generazione e trasferimento di chiavi AES.
  • Un'estensione del browser può modificare effettivamente il tuo JavaScript. Considera il raggruppamento del JavaScript come estensione del browser per un maggiore controllo su quella parte.
risposta data 25.01.2013 - 23:24
fonte

Leggi altre domande sui tag