Esiste una minaccia alla sicurezza dovuta alla restituzione della password nel modulo che invia un errore (ad esempio in una pagina di registrazione)?

4

Diciamo che abbiamo una pagina di registrazione su un sito web, perché non dovremmo restituire password come nome utente, nomi o qualsiasi altra informazione sul modulo che presenta un errore?

Ad esempio:

  • L'utente visita example.com/signup.php e inserisce il nome utente, il nome, l'e-mail e la password desiderati. L'utente deve inserire anche un captcha.

  • Inserisce tutto correttamente tranne captcha.

  • Il sito web avverte l'utente che ha inserito il valore di captcha in modo errato e ricarica automaticamente nome utente, nome e input e-mail in base ai valori già inviati, ma lascia vuoto l'input della password!

In questa fase in cui è necessario ricaricare la password, una percentuale importante di utenti (proprio come me, a volte) interromperà la registrazione e lascerà il sito Web.

Qual è il vantaggio in termini di sicurezza che utilizza questo metodo?

    
posta Amirreza Nasiri 26.08.2016 - 00:08
fonte

2 risposte

2

Fastidioso, non è vero? Sicurezza e usabilità sono spesso in disaccordo.

In questo caso, il rischio è piuttosto piccolo, ma è lì. Immagina quanto segue:

  1. Immetti tutte le tue informazioni, inclusa la password, e invia
  2. Perderai temporaneamente la tua connessione wifi, o qualcosa accade sulla rete per far sì che la risposta sia incredibilmente lenta
  3. Perdere la pazienza, ti allontani dal computer
  4. Un minuto dopo, la pagina esegue il rendering, inclusa la tua password
  5. Un utente malintenzionato cammina, fa clic su Ispeziona elemento e impara la password

Ovviamente, non è una password che funzionerà (dopotutto la tua registrazione è fallita), ma forse usi la stessa password per tutto. Chissà? Ad ogni modo, il rischio è piuttosto piccolo qui.

C'è anche un problema di usabilità. La password potrebbe essere stata sovrascritta da uno dei componenti aggiuntivi del gestore password o dal portachiavi iCloud o qualcosa del genere. Poiché non è possibile visualizzare il valore della password, non è possibile essere sicuri al 100% che sia impostato sul valore desiderato quando si invia nuovamente il modulo. Se è sbagliato, finirai per incontrare ogni tipo di dolore e confusione. Quindi forse è più sicuro solo per farti digitare di nuovo.

Personalmente, se stavo progettando il sito web, inserisco i campi di immissione dei dati della password nella sua pagina, dopo aver completato correttamente tutti gli altri campi, incluso CAPTCHA.

    
risposta data 26.08.2016 - 02:15
fonte
1

Un altro vettore di attacco da considerare è Session Hijacking. Supponendo che stai usando Post-Redirect-Get (che dovresti essere in generale), dovresti salvare la password nella sessione per poterla inviare di nuovo via GET. Mentre la sessione si trova in un luogo attendibile e relativamente sicuro (sul tuo server), la memorizzazione di testo normale o password crittografate in modo reversibile consente alla tua sessione di memorizzare un obiettivo ancora più grande. Ma diciamo che è quello che fai.

Supponiamo che un utente malintenzionato ottenga o elabora la variabile di sessione dell'utente. L'utente inserisce la password ma fallisce il modulo. Chiunque emetta una richiesta GET con quella variabile di sessione (che potrebbe essere l'autore dell'attacco) riceve la password in chiaro. Questo è peggio di un dirottamento di sessione standard, perché un dirottamento standard consentirebbe solo all'utente malintenzionato di impersonare l'utente, non ottenere password che potrebbero essere valide per altri siti.

Naturalmente, puoi mitigarlo con le difese di dirottamento di sessioni standard: la rigenerazione del token al caricamento o semplicemente il rendering su post invece di evitare completamente la sessione. (Per favore, non farlo, avere il browser che mi disturba quando riaprio o ricarico una pagina è frustrante, soprattutto perché lo faccio molto grazie al non-script.)

Meno posti la password esiste, meno bersagli per l'attacco. Se devi fare questa funzione, o vai con il suggerimento di commento di Andre per rimuovere completamente il campo della password con un pulsante per cambiarlo, o riempire il campo della password con una password standard, ma non valida (cioè inferiore alla tua lunghezza minima) che puoi controlla per quando hai memorizzato una password. Basta non inviare password reali, anche su HTTPS.

    
risposta data 01.09.2016 - 17:36
fonte

Leggi altre domande sui tag