parse.com security

Question

Recentemente ho scoperto quanto sia utile e facile parse.com. Accelera lo sviluppo e ti offre un database disponibile per archiviare tutti i dati provenienti dalla tua app web/mobile.

Ma quanto è sicuro? Da quanto ho capito, devi incorporare la tua chiave privata dell'app nel codice, garantendo così l'accesso ai dati.

Ma cosa succede se qualcuno è in grado di recuperare la chiave dalla tua app? L'ho provato io stesso. Mi ci sono voluti 5 minuti per trovare la chiave privata da un APK standard, e c'è anche la possibilità di creare un'app Web con la chiave privata codificata nel tuo javascript source dove praticamente chiunque può vederlo.

L'unico modo per proteggere i dati che ho trovato sono ACL (https://www.parse.com/docs/data), ma questo significa comunque che chiunque potrebbe essere in grado di manomettere i dati scrivibili.

Qualcuno può illuminarmi, per favore?

Answer 1

Come con qualsiasi server di back-end, è necessario proteggersi da client potenzialmente dannosi. Parse ha diversi livelli di sicurezza per aiutarti in questo.

Il primo passaggio è ACLs, come hai detto. È inoltre possibile modificare permissions nel browser dei dati per disabilitare i client non autorizzati dall'effettuare nuove classi o aggiungere righe o colonne alle classi esistenti.

Se questo livello di sicurezza non ti soddisfa, puoi proxy l'accesso ai dati tramite Cloud Functions. È come creare un server di applicazioni virtuali per fornire un livello di controllo degli accessi tra i tuoi clienti e il tuo archivio dati di back-end.

Answer 2

Ho seguito il seguente approccio nel caso in cui avevo solo bisogno di esporre una piccola vista dei dati dell'utente a un'app web.

a. Crea un oggetto secondario che contiene un sottoinsieme dei campi degli oggetti protetti.

b. Utilizzando gli ACL, rendere l'oggetto sicuro accessibile solo da un accesso appropriato

c. Rendi pubblico l'oggetto secondario read

d. Scrivi un trigger per mantenere sincronizzato l'oggetto secondario con gli aggiornamenti al primario.

Uso anche le funzioni cloud la maggior parte del tempo, ma questa tecnica è utile quando è necessaria una certa flessibilità e può essere più semplice delle funzioni cloud se l'oggetto secondario è una vista su più oggetti protetti.

Answer 3

Quello che ho fatto è stato il seguente.

1. Limita lettura/scrittura per pubblico per tutte le classi. L'unico modo per accedere ai dati della classe sarebbe attraverso il codice cloud.
2. Verificare che l'utente sia un utente connesso utilizzando il parametro request.user e se la sessione utente è nullo e se l'ID oggetto è legittimo.
3. Quando l'utente viene verificato, consentirei il recupero dei dati utilizzando la chiave master.

Answer 4

Basta mantenere un controllo stretto sulle opzioni di sicurezza a livello globale (creazione di classi client, ecc ...), Opzioni di sicurezza a livello di classe (è possibile ad esempio disabilitare i client eliminando le voci di installazione. È anche comune disabilitare la creazione di campi utente per tutte le classi) e, soprattutto, controllare gli ACL.

In genere utilizzo i trigger beforeSave per verificare che gli ACL siano sempre corretti. Quindi, ad esempio, _Soggetti utente sono dove si trova l'email di recupero. Non vogliamo che gli altri utenti siano in grado di vedere le email di recupero degli altri, quindi tutti gli oggetti nella classe _User devono avere la lettura e la scrittura impostate solo dall'utente (con public read false e public write false).

In questo modo solo l'utente stesso può manomettere la propria riga. Gli altri utenti non noteranno nemmeno che questa riga esiste nel tuo database.

Un modo per limitarsi ulteriormente in alcune situazioni, è utilizzare le funzioni cloud. Supponiamo che un utente possa inviare un messaggio a un altro utente. È possibile implementarlo come un nuovo messaggio di classe, con il contenuto del messaggio e i puntatori all'utente che ha inviato il messaggio e all'utente che riceverà il messaggio.

Poiché l'utente che ha inviato il messaggio deve essere in grado di annullarlo e poiché l'utente che ha ricevuto il messaggio deve poterlo ricevere, entrambi devono poter leggere questa riga (quindi l'ACL deve disporre delle autorizzazioni di lettura per entrambi). Tuttavia, non vogliamo che nessuno di loro manomettere il contenuto del messaggio.

Quindi avete due alternative: o create un trigger beforeSave che controlla se le modifiche che gli utenti stanno cercando di fare su questa riga sono valide prima di accettarle, o impostate l'ACL del messaggio in modo che nessuno abbia permessi di scrittura e crei le funzioni cloud che convalida l'utente, quindi modifica il messaggio utilizzando la chiave master.

Il punto è che devi fare queste considerazioni per ogni parte della tua applicazione. Per quanto ne so, non c'è modo di aggirare questo.