Sito Web che accetta l'autenticazione tramite GET

Domanda 1: questo non è considerato sicuro per una serie di motivi:

1. La password può essere vista sull'URL

2. La password può essere vista nella cronologia del browser

3. Tutte le password saranno sui log del server

4. Se l'utente accede al sito e c'è un collegamento che punta a un sito esterno e l'utente fa clic, la password viene persa

5. Lo spyware con monitoraggio degli URL sarà in grado di ottenere la password

Penso che il problema n. 3 sia il più problematico. Se qualcuno accede al server web, avrà tutte le password per ogni utente registrato, in testo normale. Vorrei licenziare la persona che progetta questo schema di accesso.

Anche se il sito utilizza SSL, tali attacchi possono essere eseguiti e ottenere le password.

Domanda 2: Questo non è un attacco, è un errore di progettazione. Apre la strada ad alcuni attacchi. Cerca CSRF (o XSRF) per il modo più semplice per attaccare questo errore di progettazione.

EDIT : quanto sopra è vero SE il modulo di autenticazione invia i dati tramite GET e non è il caso.

Se l'utente malintenzionato può creare un modulo per convincere l'utente a fornire il suo nome utente e la sua password, non importa quanto sia sicuro il lato server. Non importa se il modulo utilizza GET o POST, HTTPS o HTTP, Javascript o applet Java o Flash o macchina virtuale che esegue Linux su asm.js.

Stai chiedendo "che cosa c'è di male nell'accettare (ma non abilitare altrimenti) l'autenticazione basata su come ottenere?"

La risposta: è una cattiva pratica che potrebbe portare a una vulnerabilità, ma non crea direttamente una vulnerabilità.

Affinché una vulnerabilità esista, deve essere in qualche modo sfruttabile e deve concedere all'attaccante qualcosa che non hanno già. In questo cAae, in che modo l'hacker sfrutterà l'autenticazione get-based?

• un utente normale utilizzerà il normale ui di autenticazione post-based. S / lui non sarà interessato dai problemi con authn get-based.
• un utente malintenzionato che può configurare il proprio authn ui basato su get e che può convincere gli utenti a autenticare il proprio authn ui non ha bisogno che non ne abbia bisogno per comunicare al server; gli utenti possono inviare le loro password direttamente al proprio server
• un utente malintenzionato che può modificare il comportamento del tuo normale ui riscrivendo il codice sorgente ha già accesso al codice sorgente e può fare molto peggio.
• un utente malintenzionato che può modificare il tuo ui in fase di runtime, tramite un attacco come xss ha già trovato una vulnerabilità xss separata e può fare molto peggio
• se l'applicazione presenta anche un problema CSRF nella schermata dell'interfaccia utente, l'utente malintenzionato può accedere come se stessi anziché dall'utente normale. Tuttavia, questo è CSRF, e l'uso di get o post non ha assolutamente rilevanza. CSRF può essere eseguito sia su get che su post, e disabilitando get non si disabilita CSRF. I due argomenti non hanno nulla a che fare l'uno con l'altro, tranne che potrebbero esistere entrambi nella schermata di accesso.
• un utente malintenzionato in grado di convincere il modulo di accesso a cambiare post per ottenere un altro utente può trarre vantaggio da questa vulnerabilità. L'applicazione codifica il metodo come post? In caso contrario, utilizza l'input dell'utente per decidere se pubblicare o ottenere? Un utente malintenzionato potrebbe inviare alla vittima un URL per accedere alla tua interfaccia utente e quell'URL potrebbe contenere i parametri necessari per cinvertare da post per ottenere - se esistono

Per quello che posso dire, non ci sono altri attaccanti rilevanti per il comportamento in questione. Ad eccezione delle domande nell'ultimo proiettile, l'attaccante che può fare uso di questo difetto è già più potente di quello che l'errore potrebbe garantire. L'attaccante che non ha quel potere non può usare questo difetto.

Tutto ciò che è stato detto, è una cattiva pratica e dovrebbe essere corretto. La correzione (e l'aggiunta di un commento nel codice che spiega il motivo) aiuterà a impedire ai futuri sviluppatori dell'applicazione di utilizzare il login get-based e l'introduzione di una reale vulnerabilità.

Se il modulo di accesso è vulnerabile a CSRF (non importa POST o GET), questo è un tipo non sicuro e noto di falsificazione: "login CSRF" link

domanda correlata: Come proteggersi dal login CSRF?