RESTful schema di sicurezza e autenticazione delle applicazioni Web

Naviga le tue risposte
4

Sto costruendo un'applicazione web in cui il front-end è un'app a pagina singola e il back-end lo serve tramite un'API RESTful. Voglio assicurarmi di implementare l'autenticazione utente con le migliori pratiche di sicurezza.

Sto pianificando un sistema che eseguirà i seguenti passaggi per garantire la sicurezza dell'autenticazione:

Registrazione (o modifica della password):

  1. L'utente invia nome utente e password al server in testo in chiaro tramite HTTPS
  2. Unico salt viene generato con la funzione urandom di Python (32 caratteri)
  3. Salt anteposto alla password
  4. Salt + password viene sottoposta a hash con bcrypt
  5. Salt e hash memorizzati nella tabella del database (database SQL, più lento del valore-chiave ma non sono troppo preoccupato per la superspeed per l'accesso)
  6. ID sessione casuale generato con urandom (32 caratteri)
  7. ID sessione memorizzato nel valore-chiave db (Chiave Redis: ID sessione, valore: id utente) e inviato al client insieme all'oggetto utente (ovviamente senza sale e hash)

Accesso:

  1. Al momento del login, l'utente invia nome utente e password al server in testo in chiaro tramite HTTPS
  2. Il server recupera il sale e l'hash dalla voce degli utenti in SQL db
  3. Salt anteposto alla password e passa attraverso bcrypt
  4. Se entrambi gli hash corrispondono, l'ID di sessione viene generato con urandom e inserito nel valore-chiave db
  5. ID sessione inviato al client con oggetto utente

Qualsiasi altra richiesta al server:

  1. Richiesta e dati inviati tramite HTTPS inclusi ID utente e ID sessione
  2. Valore chiave db cercato con ID utente, se gli ID sessione corrispondono, restituiscono i dati richiesti insieme all'oggetto utente
  3. Se non corrisponde, restituisci l'errore 401

Gestione sessione:

  1. Permetti più di una sessione per lo stesso utente
  2. Imposta la scadenza della sessione a 24 ore, quando si accede, torna a 24 ore
  3. Permetti la sessione persistente che scade tra 1 mese, quando si accede anche al tempo di scadenza completo
  4. Al logout, rimuovi la sessione da Redis

Sarà un sistema sicuro, scalabile e veloce (quando necessario)? Se no, dove sono i difetti di sicurezza? Cosa potrei fare per migliorare questo processo? È vulnerabile agli attacchi CSRF? Migliora la sicurezza per aggiungere l'indirizzo IP del client e USER_AGENT alla sessione o è eccessivo?

    
posta Tom Grant 30.01.2015 - 04:20
fonte

1 risposta

0

L'autenticazione è un meccanismo complesso con molti potenziali errori di sicurezza che dovrebbero essere risolti.

TLDR: usa Open ID per l'autenticazione invece di implementare il tuo meccanismo.

  1. Brute Force: devi prenderti cura della protezione contro la forza bruta nell'autenticazione (limitare il numero di tentativi errati di accesso) e anche proteggere contro la forza bruta del tuo ID di sessione. Se fossi un aggressore, ho solo forzato la coppia di ID e ID di sessione fino a quando non ottengo 401 ... ora ho una sessione valida. Devi bloccarlo anche dopo. È possibile utilizzare un HMAC per firmare l'ID di sessione. In questo modo un utente malintenzionato non può indovinare la tua chiave segreta usata per HMAC l'ID di sessione e non può forzarla.
  2. Furto di ID sessione. Non hai specificato in che modo l'ID sessione viene rinviato all'utente. Presumo che intendessi inviarlo per script lato client da gestire e inviare con ogni richiesta successiva. Ciò rende il tuo ID sessione suscettibile di furto dallo script lato client (causato da XSS, ad esempio), il modo per proteggerlo è inviarlo in un cookie con il flag "solo http" impostato in modo che gli script non possano accedervi ( devi assicurarti di impostare anche il flag" sicuro "e limitare il tuo dominio ecc ... )
  3. Il tuo meccanismo non consente all'utente il metodo "ricordami", quindi l'utente dovrà eseguire nuovamente l'autenticazione ogni volta che apre l'app, mantenendo risolto l'ID di sessione in un cookie.
  4. CSRF - se la sessione viene mantenuta in un cookie persistente, diventa vulnerabile a CSRF. Il modo per proteggersi da ciò è utilizzare un token anti-CSRF altrimenti noto come Pattern token di sincronizzazione

Con tutto questo in mente ... la mia raccomandazione finale per te è usare l'open ID per autenticare i tuoi utenti, mantenere il duro lavoro dell'autenticazione per i big guys e solo assicurarti di usarlo correttamente, che ti farà risparmiare di mal di testa e tempo e probabilmente alla fine sarà più sicuro.

    
risposta data 30.01.2015 - 13:24
fonte

Leggi altre domande sui tag

EIP viene modificato in Fgetc () Buffer Overflow Homework Che cosa fa la StarVision di Lockheed e quali sono alcuni prodotti comparabili sul mercato? [chiuso]