Come proteggere la chiave dell'API Rest per Parse nell'applicazione html

Question

Ho studiato con Angular.js e ho utilizzato Parse come servizio di back-end. Per pubblicare i dati alle API RESTful Parse, si passerebbe chiave API REST e App ID nell'intestazione della richiesta in questo modo:

var config = {headers: {"X-Parse-REST-API-Key":"someapikey", "X-Parse-Application-Id":"someappid"}}; 

$http.post("https://api.parse.com/1/classes/myobject", obj, config).success (
      function(data) {console.log(data);} 
); 

Mentre questo è grande per l'apprendimento, mi chiedo come sarebbe il RESTful API per Parse o qualsiasi altro fornitore di backend-as-service funziona in una vera applicazione html. La chiave API e l'ID applicazione verranno esposti in JavaScript e chiunque sia abbastanza intelligente da visualizzare l'origine potrebbe modificare i dati nel tuo account.

L'unico modo in cui riesco a immaginarlo funziona con un server proxy che aggiunge all'intestazione ID chiave/app Api. Tuttavia, ciò annullerebbe lo scopo di non dover eseguire il proprio server back-end. Mi sto perdendo qualcosa qui?

Answer 1

Parse offre diverse chiavi di accesso che possono essere utilizzati tramite diverse API:

• chiave del client (per l'utilizzo da iOS e applicazioni Android)
• Javascript chiave
• di Windows chiave
• REST chiave
• Chiave principale (da utilizzare per l'accesso all'API REST, ma non conforme alle autorizzazioni ACL dell'oggetto)

Quando si accede a Parse dal javascript sul lato client, è necessario utilizzare l'API javascript con la chiave di accesso Javascript.

In termini di sicurezza, non sarà possibile impedire agli utenti di utilizzare una chiave di accesso utilizzata dal lato client javascript. Parse fornisce un potente controllo degli accessi tramite ACL collegati a ciascun oggetto, consentendo di limitare l'accesso in lettura/scrittura a ogni classe agli utenti specificati. Puoi anche impedire ai clienti di creare nuove classi nelle impostazioni della tua app. Dai un'occhiata alla guida alla sicurezza here.

Answer 2

Ecco cosa vi state perdendo :)

I tasti Parse.com REST/JavaScript sono progettati per essere "out-in-the-wild". Con queste chiavi non è possibile aggirare le regole di accesso agli oggetti o prima delle convalide Salvataggio. Solo la chiave master può farlo. Proteggi la chiave principale. Un'analogia utile è la crittografia a chiave pubblica: è necessario condividere la chiave pubblica, ma proteggere la chiave privata.

Qualcuno può modificare i dati? Sì, ma solo se li si lascia. Gli utenti possono interrogare i dati appartenenti ad altri utenti? Sì, ma di nuovo solo se li si lascia. Parse ha alcuni modi per garantire l'integrità e la sicurezza dei dati.

Il primo è autorizzazioni per oggetto. Utilizza l'interfaccia web Parse.com per impostare a) se le classi possono essere create o meno al volo eb) le autorizzazioni CRUD per le classi esistenti. Uno dei passaggi più semplici per proteggere un'app consiste nel disabilitare qualsiasi autorizzazione di classe non esplicitamente richiesta. Ad esempio, oggetti creati sul back-end che non devono essere scrivibili (o forse leggibili) dagli utenti finali.

Il secondo è l'elenco di controllo di accesso (ACL). ACL sono impostati su ogni record. Specificano quali utenti o ruoli possono leggere o scrivere il record. I record senza ACL sono pubblici (qualsiasi utente può trovarli). Se Sue crea un record che dovrebbe essere privato per lei, imposta un ACL come tale. Tom non sarà in grado di trovarlo senza la chiave principale.

Il terzo è il codice Cloud. Sei in grado di applicare le regole aziendali mission critical e le convalide dei dati utilizzando le funzioni beforeSave/afterSave. Determina ciò che è veramente importante e assicurati che sia convalidato in queste funzioni. È anche una buona idea impostare esplicitamente l'ACL in queste funzioni. Gli ACL possono essere passati dentro quando si crea l'oggetto, ma è possibile che l'utente finale li manchi.

Ecco le regole generali per la sicurezza e l'integrità.

• Le autorizzazioni degli oggetti devono essere aperte solo se necessario per supportare i requisiti.

• Ogni record deve avere un ACL, a meno che non si sia sicuri che non dovrebbe.

• La maggior parte degli ACL deve essere impostata con le funzioni before/afterSave.

• Qualsiasi convalida che deve essere applicata a deve essere verificata per le funzioni before/afterSave.

Ultima cosa: è allettante pensare a tutte le logiche di business come "importanti" e insistere su "perfetta integrità". Questo è eccessivo per molte app. Assicurati di disporre di una protezione sul lato server sufficiente in modo che un utente non possa mai causare danni a te o agli altri utenti. Non ha molto senso preoccuparsi molto oltre a questo (a parte i costi di supporto). Se qualcuno sta sperimentando con la tua app ma è impedito di interferire intenzionalmente o involontariamente con gli altri, forse troveranno un modo completamente nuovo di usarlo :).