Hot Towel/Durandal/Breeze.js: come proteggere le chiamate dati in verticale?

Question

Sono nuovo per l'intero mondo SPA sul lato client. Sto usando le tecnologie di cui sopra, che sembrano abbastanza promettenti. Tuttavia, un enorme ostacolo che non riesco a superare facilmente è la mancanza di sicurezza integrata. Ho dovuto rilasciare manualmente l'autorizzazione dell'utente, che IMHO dovrebbe essere parte del framework.

Ora che l'ho ordinato, sto riscontrando grossi grattacapi con sicurezza verticale: dove un utente è loggato ma può accedere facilmente alle informazioni di altri utenti modificando alcuni parametri nella console del browser. Potrei passare l'ID utente con ogni chiamata e quindi confrontarlo con quello sul server, ma speravo che ci sarebbe stata una soluzione globale che non inquinava le chiamate dati di brezza con gli ID utente.

Per esempio, diciamo che c'è una chiamata dal servizio dati in questo modo:

function getItems(){   
     var query = breeze.EntityQuery.from('Items').expand("Person"); 
     return manager.executeQuery(query); 
} 

In questo modo ottenere tutti gli elementi, non va bene. Quindi cerchiamo di limite per UserID:.

function getItems(userId){   
     var query = breeze.EntityQuery.from('Items').where("userId", "==", authentication.userId).expand("Person"); 
     return manager.executeQuery(query); 
} 

nel secondo esempio, si ottiene l'ID utente del servizio di autenticazione, che memorizzato l'ID utente quando l'utente è stato registrato in Tuttavia, un utente malintenzionato può facilmente andare alla console browser e cambia quel valore.

Ovviamente, potrei passare l'ID utente usando con Parametri (...) e confrontarlo con quello corrente sul server, ma dovrei farlo per ogni chiamata, che non sembra corretta. C'è un modo migliore per proteggere le chiamate con l'ID utente fidato?

Answer 1

@ Ali - Capisco il tuo dolore e la tua preoccupazione. Hai ragione a temere qualsiasi forma di sicurezza cosiddetta che si basa sulle informazioni passate nell'URL. Fortunatamente ci sono ottime risposte alle tue preoccupazioni e le app Breeze funzionano bene con loro.

Ad esempio, hai studiato il ASP.NET Breeze/Knockout Template? Utilizza Autenticazione moduli per l'autenticazione e protegge il controller API Web con un attributo [Authorize]. Solo gli utenti loggati possono accedere a qualsiasi metodo del controller.

Tale autenticazione imposta anche lo IPrincipal che il controller API Web rende disponibile tramite la sua proprietà User. Verrà visualizzato il numero User passato al costruttore dello TodoRepository. In quel repository troverai la logica di guardia per limitare le query e salvare solo le informazioni Todo appartenenti all'utente richiedente.

Controllare il traffico di rete. Non troverai alcuna informazione identificativa dell'utente nell'URL o negli organismi di richiesta/risposta. Vedrai un cookie di autenticazione crittografato in un'intestazione.

Un difetto evidente nell'esempio è che il traffico client/server si svolge in chiaro. È necessario aggiungere la sicurezza del livello di trasporto (HTTPS) prima di andare in produzione. Ma questa è una demo, dopo tutto.

Answer 2

Perché non farlo nel controller? Se Web Api è protetto con [Autorizza], è possibile ottenere l'ID utente nel controller e assicurarsi che i dati restituiti siano per l'utente attualmente connesso.