Protezione di un'app JavaScript con RESTful backend

5

Ho esaminato la domanda Protezione di un singolo JavaScript App di pagina con backend RESTful che contiene discussioni / opzioni relative alla protezione di un'app per client JavaScript che richiama API RESTful.

Tuttavia, dalle discussioni, non è chiaro come il "segreto condiviso" utilizzato per il calcolo dell'HMAC sia tenuto al sicuro dal lato del cliente. La memorizzazione di tale segreto condiviso in un cookie (che è accessibile dagli script) o anche nell'archiviazione locale non è buona poiché questi sono vulnerabili alle perdite. Le chiavi sono generate dinamicamente in modo che ogni round trip sul server restituisca una nuova chiave che deve essere utilizzata per calcolare l'HMAC per il prossimo round trip?

    
posta mithrandir 03.04.2015 - 05:24
fonte

2 risposte

1

In primo luogo, alcune cose:

  • Non esiste un segreto condiviso nella risposta di Thomas Pornins alla domanda collegata. Il server utilizza un segreto che solo conosce per calcolare l'HMAC. Il client ottiene quindi HMAC e lo invia al server su ogni reqeust come token di autenticazione. Il server può controllarlo ricalcolandolo con i server segreti. Si noti che il client non calcola mai un HMAC.
  • Piuttosto che implementarlo tu stesso, probabilmente vorrai utilizzare una soluzione esistente, come JWT.

Tuttavia, HMAC o JWT o qualsiasi altra cosa deve essere mantenuta sul lato client sicuro. Personalmente, l'ho messo nella memoria locale ma un cookie potrebbe funzionare anche. Li domini perché sono vulnerabili alle "perdite". Potrebbe essere vero che il malware eseguito come root o qualcuno con accesso fisico potrebbe rubarli. Questo è un rischio. Ma ecco il punto: tutto il sistema di accesso, dagli ID di sessione vecchio stile ai JWT moderni, funziona lasciando che il cliente memorizzi un segreto. Se non è possibile accettare tale rischio, non è possibile avere accesso e sarà necessario che l'utente ridigita la password su ogni richiesta. (Ma chi lo sa, il malware che può leggere lo storage locale potrebbe potenzialmente leggere anche le battiture ...)

Non sei sicuro di cosa intendi con l'utilizzo di un nuovo segreto per ogni round trip, ma non è stato in grado di risolvere il dilemma di cui sopra. Alla prima richiesta, il client autentica se stesso con una password e ottiene un segreto che può utilizzare per l'autenticazione futura in cambio. Alla richiesta successiva, il client deve autenticarsi di nuovo. O ha salvato il segreto e può usarlo. Oppure no, e quindi l'utente deve ridigitare la password.

    
risposta data 13.05.2018 - 11:08
fonte
0

I miei sette centesimi qui ... Niente può essere sicuro al 100%. Ma il 99% è fattibile. Potresti utilizzare l'HMAC o anche un algoritmo RSA con JWT (presumo che tu sia esperto di JWT. In caso contrario, ecco un buon articolo ). Il token viene generato utilizzando detto algoritmo una volta su ogni accesso utente riuscito. Il segreto è memorizzato solo sul lato server, ma ci sono stati usi di client nonces (leggi più qui ). Potresti passare il segreto tra client e server, ma dovrebbe essere dinamico e la rigenerazione dei token potrebbe influire sulle prestazioni. Puoi disattivare l'accesso ai cookie tramite script abilitando la proprietà HttpOnly sui cookie che vengono emessi dal server. Potresti anche impostare tempi di scadenza brevi per i token, quindi in caso di furto scadono poco dopo. Assicurati di stabilire TLS 1.0 o superiore per qualsiasi e tutte le comunicazioni tra client e server e magari qualche monitoraggio e avviso sugli eventi generati dall'app. Tutto il meglio:)

    
risposta data 14.03.2018 - 04:56
fonte

Leggi altre domande sui tag