Dovrei usare una SPA JavaScript progettata quando la sicurezza è importante

5

Ho chiesto qualcosa di simile sullo stackoverflow con un particolare pezzo di codice, tuttavia voglio provare a chiedere questo in un senso più ampio.

Quindi ho questa applicazione web che ho iniziato a scrivere in backbone usando una Single Page Architecture (SPA), tuttavia sto iniziando a indovinarla per sicurezza. Ora non stiamo archiviando e inviando informazioni sulla carta di credito o cose simili attraverso questa applicazione web, ma stiamo memorizzando informazioni sensibili che le persone ci stanno caricando e che potremo riscaricare anche.

L'evidente preoccupazione per la sicurezza che ho con JavaScript è che non ti puoi fidare di nulla che provenga da JavaScript, tuttavia in un'applicazione Backbone SPA, tutto viene inviato tramite JavaScript. Ci sono due funzionalità di sicurezza che dovrò creare in JavaScript; permessi e autenticazione.

Il pezzo di autenticazione non è altro che un override del metodo Backbone.Router.prototype.navigate per controllare il frammento che sta tentando di caricare e se il JavaScript application.session.loggedIn non è impostato su true (e non visualizzano nessuno pagina autenticata), vengono reindirizzati automaticamente alla pagina di accesso. L'utente può facilmente modificare application.session.loggedIn in modo che corrisponda a true (o modificare il metodo Backbone.Router.prototype.navigate), ma in tal caso non dovrebbero anche incorporare in modo così semplice un link nella pagina (o modificarne uno corrente) che ha le classi, gli attributi data- * e i valori href corretti per caricare una pagina che deve essere caricata solo quando l'utente ha effettuato l'accesso (e dispone delle autorizzazioni).

Quindi ho un oggetto acl che si occupa delle cose dei permessi. Tutto ciò che qualcuno dovrebbe fare per visualizzare pagine o parti di pagine che non dovrebbero essere in grado di chiamare acl.addPermission (risorsa, permesso) con le autorizzazioni appropriate o modificare acl.hasPermission () per restituire sempre true e quindi navigare lontano e poi di nuovo alla pagina.

Ora alcune cose sono come EMCAScript 5 come Object.seal () o Object.freeze () aiuterebbe con alcune di queste funzionalità, ma dobbiamo supportare IE 8 che non supporta tali funzionalità.

Ora l'API REST esegue anche controlli di sicurezza su ogni richiesta, quindi tecnicamente anche se sono in grado di vedere parti dell'interfaccia a cui non dovrebbero essere in grado, non dovrebbero comunque essere in grado di influenzare alcun dato.

I principali vantaggi per me nello sviluppo di un'applicazione JavaScript SPA è che l'applicazione è molto più reattiva poiché trasferisce solo la quantità minima di dati JSON per l'azione richiesta e esegue anche la quantità minima di lavoro. Ci sono anche altre cose che penso siano utili come se dovessi sviluppare un'API per i dati (che è buona se vuoi espandere la tua applicazione su piattaforme / tecnologie diverse) o la loro è più una separazione tra front-end e back-end, tuttavia, se la sicurezza è un problema, è davvero consigliabile percorrere la strada di un'applicazione JavaScript SPA per il front-end?

    
posta ryanzec 17.09.2012 - 18:27
fonte

2 risposte

2

Non mi baserei sul javascript del client per dirti se l'utente è loggato. Può essere facilmente modificato.

Il paio di volte che ho creato interfacce web di tipo "pagina singola", l'ho fatto con due "pagine". La prima pagina incontrata era una pagina di accesso. Una volta inviato, ciò consentiva la creazione di una sessione web tradizionale sul server, e quindi restituiva la pagina 'applicazione', che quindi caricava immediatamente tutto da richieste ajax. Per tutte le successive chiamate ajax il cookie è stato inviato con la richiesta, quindi l'autenticazione ha funzionato come nelle applicazioni tradizionali. Quindi non c'è niente di particolare che devi fare in modo diverso nel tuo javascript per supportare questo. Ovviamente, ogni risposta lato server deve convalidare la sessione.

Dico due "pagine", ma erano davvero le stesse "index.php": restituiva solo una pagina di accesso o la pagina principale dell'applicazione a seconda che fosse stato impostato un "accesso" valido nella sessione lato server . Nel tuo caso, avresti semplicemente il nodo che restituisce due diversi modelli di pagina.

    
risposta data 17.09.2012 - 20:18
fonte
2

Le SPA possono essere altrettanto sicure di qualsiasi applicazione web. Non sono meno sicuri. Hai molte opzioni che dipendono dai tuoi requisiti di sicurezza. Alcuni sono discussi in questa Domanda StackExchange sulla sicurezza . Ci sono molte indicazioni sul web per proteggere le SPA. Sto lavorando a un progetto SPA in cui utilizziamo una combinazione di autenticazione di base e cookie per mantenere l'identità della sessione sul server. Ogni chiamata a un'API REST per i metodi AJAX è autorizzata sul server. Se le autorizzazioni falliscono, restituiamo un errore Proibito HTTP al client e lo gestisce di conseguenza. Siamo in grado di mantenere una vera applicazione a singola pagina utilizzando una finestra di dialogo modale dell'interfaccia utente jQuery per il log-on. Non manterrei le informazioni di sessione specifiche sull'identità sul client o non imposto le autorizzazioni sul client. E ovviamente vuoi ancora utilizzare HTTPS / SSL per proteggere i dati sul filo.

    
risposta data 18.10.2012 - 21:38
fonte

Leggi altre domande sui tag