Problemi di sicurezza per l'implementazione di Single Sign-On

2

Sto provando a creare un singolo segnale sul sistema che collega l'app da A a B e da B a A. Sfortunatamente, l'opzione per utilizzare OpenID / OAuth / SAML non è possibile al momento, quindi sto costruendo una soluzione di base da solo , ecco come va:

  1. L'utente accede all'App A
  2. L'utente fa clic sul link "Vai all'app B"
  3. Server per l'app A genera un token JWT contenente l'ID utente e la data di scadenza, salva un output con hash di questa stringa in una posizione condivisa (come Redis) e reindirizza all'endpoint di App B insieme al token
  4. App B hash il token che ha ricevuto e controlla se corrisponde all'hash che si trova nel database. Se corrisponde, verifica se il token è scaduto e rifiuta / accetta la richiesta in base alla valutazione.
  5. L'app B richiama l'app A insieme al token e un messaggio "SUCESS".
  6. L'app A esegue nuovamente il hashing del token e controlla nel database per vedere se i due hash corrispondono. In tal caso, l'App A emette un token di autenticazione temporaneo sul client.
  7. Per tutte le future richieste all'App B, l'App A passa il token temporaneo (che l'App B convalida con una chiave segreta) e l'App B garantisce la richiesta (se non è scaduta e rifiuta se scaduta)

Questo è l'approccio che è stato implementato e funzionale, ma volevo sapere quanto è sicura la logica. Vedi ovvi problemi di sicurezza con questa implementazione?

    
posta DemCodeLines 22.04.2018 - 04:57
fonte

1 risposta

1

Come i colleghi hanno sottolineato, la tua logica SSO è sana qui. Per migliorarlo un po 'e renderlo più veloce forse, puoi terminare in Passaggio 3 se usi la chiave privata nel Server B per convalidare il JWT generato dal server A.

Naturalmente, assumiamo alcune cose qui ad ogni passaggio, ad esempio:

  1. Crittografia = > stiamo assumendo che l'intero sistema stia usando un robusto meccanismo di crittografia per passare questi token JWT avanti e indietro e sono al sicuro da occhi indiscreti.

  2. Il server A e il server B convalidano l'input gli uni dagli altri - in altre parole, il server B non si fida implicitamente che il server A invii sempre token JWT, poiché le richieste / risposte possono essere intercettate.

  3. Attacchi Denial of Service: il sistema può respingere questi attacchi.

  4. Velocità - sufficientemente veloce

  5. Avvisa l'amministratore di altri attacchi di sicurezza

risposta data 26.09.2018 - 22:19
fonte

Leggi altre domande sui tag