Sicurezza del token di sicurezza Passportjs

Diversi professionisti AppSec hanno opinioni diverse su questo. Ho conosciuto alcuni che hanno sostenuto che questa è una vulnerabilità.

Personalmente, penso: "dipende" (lo so, quella frase è cliché).

Due motivi:

1. Se un utente autenticato sta collaborando con un utente malintenzionato o se è un utente malintenzionato, è necessario accettare che l'applicazione & i dati sono esposti nella misura in cui l'utente ha accesso. Tratto questo come "hey questo è praticamente lo stesso come l'utente che passa le sue credenziali di accesso" - anche se tecnicamente è diverso.

2. Lo stesso vale se il sistema / browser del client viene compromesso nella misura in cui un utente malintenzionato ha accesso a tutto ciò che lo contiene.

Tuttavia, spostando i cookie di sessione da un browser a un altro o peggio, un sistema a un altro è difendibile in una certa misura - attraverso l'uso di nonce per conversazione e / o mantenendo altre informazioni sul profilo del client come UA Strings e IP indirizzi. Ci sono dei limiti su quanto lontano puoi andare con questa linea di difesa, ma poi nessuna singola difesa è sufficiente contro un determinato attaccante.

I token di sessione sono considerati segreti, se li copi da un browser a un altro, è normale che tu possa effettivamente accedervi mentre le tue applicazioni guardano questi valori per verificare l'identità.

Se stai usando uno strumento proxy web come il rutto, gli hacker hanno già eseguito con successo un man-in-the-middle. Ecco perché utilizziamo SSL / TLS: per crittografare il traffico in modo che questo token sensibile non perda.

Ci sono alcune azioni di attenuazione che puoi intraprendere come controllare l'agente utente o gli indirizzi IP per ogni sessione. Se questi cambiano, invalidi immediatamente la sessione.