Inserimento dell'indirizzo IP nel token Web JSON o nel cookie di sessione

Vedo alcune cose a cui pensare:

1. Dovresti assicurarti che un tentativo di accesso sia valido solo quando   il client ti invia un cookie di sessione valido. Altrimenti, l'attaccante   non posso semplicemente inviare un cookie di sessione e genererai felicemente un   nuovo per lui per ogni tentativo di accesso. Questo sembra essere un problema difficile da risolvere. Come imponi a un utente malintenzionato di inviarti un cookie se non lo desidera?

2. Perché pensi che i tentativi di accesso provengano tutti dallo stesso indirizzo IP? Cosa succede se hai un attacco lanciato da più IP?

3. Che cosa accade se un utente malintenzionato non tenta di attaccare un singolo utente, ma tenta un intero intervallo di nomi utente e password? Ciò significa che non rileverà un attacco in corso, perché non ci saranno più tentativi di accesso per qualsiasi utente in rapida successione.

IMO, non puoi andare in giro mantenendo uno stato persistente lato server sulla frequenza globale delle richieste al tuo endpoint di accesso (o di fatto a qualsiasi endpoint), indipendentemente da chi il client sembra essere e se ottieni un cookie di sessione o no.

I pacchetti open source (quelli stabili e rinomati che vengono spediti con distribuzioni mainstream) sono un rischio molto più piccolo di consiglio open source ;) Ci sono montagne di cattivi consigli là fuori. Oh BTW, questo consiglio è abbastanza legittimo! ;)

Una buona dose di scetticismo (non paranoia) fa bene alla sicurezza e sei partito per un buon inizio.

In generale:  1. Hai bisogno di più protezioni per lavorare insieme. Non esaminare una sola minaccia in modo isolato, ma esamina alla fine se stai coprendo tutte le minacce, almeno in una certa misura.  2. La completa prevenzione in tutte le circostanze è grande, ma il più delle volte, innalzare le barriere per renderlo antieconomico per gli attaccanti non bersaglio è sufficiente.

Più in particolare:

1. In generale, odio i captcha come utente. Quindi non li uso nei sistemi che sviluppo. Se devo sopportarne una, una semplice barriera (vedi il principio 2 sopra) come quello che CloudFlare usa è ciò che preferisco. Ultimo controllo è una combinazione di analisi lato server (come le richieste bot in genere arrivano a frequenze diverse rispetto agli umani), alcune JS per rilevare le caratteristiche del browser (arresto generale dei bot con spoofing stringa UA), un piccolo ritardo sub-secondo iniettato per rallentare i bot ma nemmeno visibile dagli umani, ecc.
2. Hai detto che userai un captcha quando rilevi tentativi di accesso falliti ripetuti. Questo è un buon modo per farlo - e indica che stai usando i controlli lato server.
3. Sono possibili più verifiche lato server (inclusi i controlli dell'indirizzo IP, se lo si desidera) anche se non sono raccomandati a causa di problemi di roaming / indirizzo IP dinamico menzionati da @ blownie55 e @Pascal. Non è necessario memorizzare l'indirizzo IP nei cookie. È sempre possibile ottenerlo dalla richiesta stessa e verificarlo rispetto alle proprietà memorizzate rispetto alla sessione.
4. In alcuni casi, "temporaneamente blocciamo gli indirizzi IP di attacco" quando rileviamo un attacco di forza bruta in corso. Qualunque cosa da 30 minuti a 1 giorno dovrebbe funzionare, a seconda della natura degli aggressori nel dominio degli asset. I domini più rischiosi in genere richiedono un blocco più lungo; i domini di utilizzo di volumi elevati richiedono blocchi più brevi; domini ad alto volume rischiosi hanno bisogno di una filosofia per intervenire.:)

Spero che questo aiuti.