Problemi di sicurezza con RESTful Authentication & Session Management

Question

Problemi di sicurezza con RESTful Authentication & Session Management

#1 da (4 voti)
#2 da (0 voti)

1

Sto cercando di implementare l'autenticazione e la gestione delle sessioni per un microservizio. Per poter eseguire il processo RESTfully, capisco che sarà necessario utilizzare una sorta di autenticazione basata su token per evitare di tracciare i dati della sessione client sul server. La seguente citazione da questa risposta sullo scambio di informazioni sulla sicurezza dello stack riassume bene il mio comprensione dell'implementazione:

In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request (It can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility a string with all the necessary information is issued (the token) which is checked after each request made by the client to the server.

Da ciò capisco quanto la manutenzione delle sessioni stateless sia vantaggiosa per la scalabilità e la flessibilità, come spiegato. Ma mi sembra che questo lasci l'applicazione esposta ad alcuni seri problemi:

Se un hacker intercetta in qualche modo la chiamata REST HTTP di scambio delle credenziali, potrebbe eseguire attacchi di replay sul server ottenere tutto il informazioni che vogliono.
Infatti, dal momento che il token di sessione è memorizzato sul lato client, un hacker non è in grado di recuperare le informazioni necessarie da LocalStorage / SessionStorage eseguendo il debug dell'applicazione? O monitorando le chiamate HTTP in entrata e in uscita usando gli strumenti di sviluppo? Se ottengono le informazioni token richieste (anche le informazioni sui token crittografate), potrebbero semplicemente iniziare a simulare le chiamate REST al server da un'altra finestra e ottenere tutti i dati che desiderano!

Infine, anche se fornisci al client un token di sessione, il server non deve ancora autenticare il token quel ? In effetti, il server dovrebbe mantenere i token di sessione per i mapping degli utenti ... ma ciò non ostacola lo scopo di un'architettura basata su REST stateless?

Forse vedo questi problemi perché c'è una lacuna nella mia comprensione. Se è così, vorrei una certa chiarezza dei concetti di base. In caso contrario, mi piacerebbe sapere se ci sono tecniche per affrontare questi problemi specifici.

security rest microservices authentication session

posta shinvu 01.11.2018 - 06:48

fonte

2 risposte

Leggi altre domande sui tag security rest microservices authentication session

Come organizzare le mie funzioni di test? Qual è l'etichetta per il rilascio di un modulo Perl basato sul modulo di qualcun altro?

score 4 · Answer 1

Questa risposta può aiutarti in termini di attacchi di replay sulla rete livello. L'uso di un "nonce" può anche aiutare a proteggere contro la stessa richiesta semantica creata più volte dallo stesso client.

In termini di un Man In The Middle (MITM) che intercetta un hash e lo riproduce al posto di una password, è vero che questo è possibile, ma allo stesso modo è possibile quando lo stato è memorizzato sul server e una sessione normale il token cookie viene scambiato, ma dovrebbe essere reso più difficile in entrambi i casi utilizzando HTTPS con una configurazione strong (crittografia strong, EDHC, protocolli moderni, HSTS con pre-caricamento, possibilmente HPKP. È possibile utilizzare link per testare la configurazione.

Usare sicuro link può anche aiutare a proteggere dalla divulgazione accidentale dello stato come potrebbe un CSP per impedire che script non autorizzati provino a eseguire l'exfiltration.

I processi, come quelli usati in JWT , potrebbero aiutarti a proteggerti dalla preoccupazione di un client malevolo che apre la loro memoria locale o cookie e modifica loro (ad esempio qualcuno che cerca di cambiare il loro stato locale che verrebbe inviato al server). Utilizzando l'infrastruttura a chiave pubblica (PKI), fornendo la chiave privata è al sicuro, questa tecnica è efficace nella convalida di una firma digitale (assicurando che lo stato del client non è stato modificato durante la lettura sul server). Questo è come fai notare nella tua domanda parte 3, il server non ha necessariamente bisogno di mappare il token client per convalidarlo, "solo" ha bisogno di convalidare l'HMAC per garantire l'integrità del messaggio prima di fidarsi dei dati).

A un livello più ampio, essere rigorosamente restful nel mantenere lo stato del client sul client, portando molti vantaggi in termini di scalabilità porta alcune sfide, come quelle che si citano qui, e in molti casi si può ottenere una scalabilità accettabile con il server Replica e partizionamento dello stato gestito lateralmente per isolare i guasti in una sottosezione più piccola dell'utente. Per esempio. pensa a Redis e gestisci l'hosting come AWS Elasticache che potrebbe renderti la vita più facile. Quando lo stato è gestito esclusivamente dal cliente, può diventare più difficile fare cose come la revoca e la scadenza prematura.

Spero che questo aiuti in qualche modo,

score 0 · Answer 2

Q: 1-2 Sì, potrebbe succedere. Gli hacker possono impersonare altri utenti se riescono a sottrarre i loro token di autorizzazione. Tuttavia, ci vorrebbe ( di solito ) per ottenere l'accesso al client dell'utente.

Per quanto riguarda le comunicazioni tra interprocessi, se le comunicazioni server-client sono sicure ( crittografate ), nessun intermediario fornirà agli attaccanti dati sensibili. Ecco perché TLS è così importante nei sistemi distribuiti. ¹

Tornando ai token rubati, per mitigare questa vulnerabilità facciamo spesso dei token di breve durata. I token scadono alla fine, costringendo i client a richiedere nuovamente il token di autorizzazione. Alcune implementazioni di sicurezza utilizzano token di aggiornamento, altre impongono ai client di eseguire nuovamente il login.

Sul lato server, ci sono alcune misure che possiamo implementare, ad esempio, possiamo espirare i token prematuramente o implementare blacklist e / o whitelist.

Q: 3 server convaliderà il token in ogni singola richiesta. Cercarlo nel DB, decodificarne il contenuto, inviare il token a qualche tipo di servizio di autorizzazione, ecc. Come faremmo con qualsiasi altra credenziale. Ovviamente, è necessario memorizzare il token da qualche parte, ma i token non sono sessioni . Non mantengono lo stato del cliente, identificano gli utenti e le autorizzazioni e, a volte, anche l'emittente del token.

Per quanto riguarda i token di sessione, se il lato server è puramente stateless non c'è nulla da preservare per quanto riguarda lo stato lato client, non c'è alcuna sessione da identificare. Lo stesso token di autorizzazione funge da token di sessione; non appena il token scade, la sessione sul lato client potrebbe farlo anche.

^{1: Esistono altri vettori di attacco come attacco di scripting cross-site , potenzialmente dannoso ma "relativamente" semplice da prevenire.}