Eventuali rischi per la sicurezza dell'autenticazione di accesso e modifica della password sulla stessa pagina?

Normally the user needs to authenticate first in order to see the password change form.

Inserendo il nome utente e la password, il sistema dovrebbe autenticare prima l'utente e una volta che l'autenticazione ha avuto successo, la password dovrebbe essere cambiata. Questo è qualcosa che non può essere verificato utilizzando l'URL di esempio che hai fornito.

Tuttavia, in questo caso, consiglierei di avere un anti Meccanismo di richiesta di cross site request implementato in questo modulo specifico per convalidare l'origine della richiesta.

Inoltre, si consiglia di implementare una sorta di meccanismo anti-scripting per impedire ai robot di indovinare le credenziali e quindi modificarle dopo un accesso riuscito. E.g .: rate limit o captcha dopo x quantità di richieste non riuscite.

Per quanto riguarda la tua domanda se ci sono dei rischi per la sicurezza, la mia risposta sarebbe: Ci potrebbe essere, ma dipende molto dall'implementazione. Sfortunatamente questo non è qualcosa che possiamo determinare senza avere un account su una di queste applicazioni.

Da quello che posso vedere sulla pagina di esempio che ci hai fornito, non esiste un meccanismo anti CSRF, che in teoria potrebbe avviare un attacco di forza bruta per tuo conto se visiti un sito Web dannoso che contiene questo tipo di codice .

Uno dei possibili rischi è che tale modulo non richiede i cookie o il supporto di sessione per accedere utilizzando la password rubata e immediatamente modificarla.

Dal punto di vista degli autori di software rogue, ci sono molti linguaggi e framework possibili, che possono essere usati per creare il loro software. Ognuno di questi richiede alcune conoscenze per iniziare. Per esempio. creare un bot che sia in grado di accedere automaticamente alla pagina Web e rubare alcune informazioni, richieste almeno conoscenze di base, come funziona la sessione HTTP, come funzionano i cookie ecc. Quindi per la maggior parte di queste pagine è piuttosto semplice ma non banale creare tale bot. / p>

Ma quando crei un modulo che consente 2 cose usando 1 richiesta, stai semplificando la scrittura di un bot che cambierà immediatamente la password rubata per impedire all'utente di effettuare il login e quindi dare l'attacker un po 'di tempo (prima reimpostazione della password da parte dell'amministratore notificato) per cercare informazioni più interessanti.

In generale, no. Non ci sono significativi ulteriori rischi per la sicurezza associati a questo approccio.

Qualsiasi utente malintenzionato in grado di modificare la password dell'utente utilizzando un modulo come questo potrebbe facilmente accedere all'account dell'utente e modificarne la password. In entrambi i casi, sono richieste le stesse informazioni (nome utente, password corrente, nuova password).

I moduli di modifica delle password sono generalmente posizionati dietro un modulo di accesso per motivi di convenienza, non di sicurezza. Se un utente ha già effettuato l'accesso, è scomodo costringerli a inserire nuovamente il nome utente prima di cambiarne la password.

Detto questo, ci sono i soliti rischi per la sicurezza di essere a conoscenza di un modulo come questo. In pratica, tutte le protezioni che normalmente inseriresti in un modulo di accesso dovresti anche metterle qui. Questo include tentativi di modifica della password limitanti la velocità e protezione del modulo contro CSRF ( in particolare se l'applicazione firma automaticamente gli utenti quando cambiano la loro password ).

Penso che ci siano pro / contro per entrambi gli approcci. Ricorda che in genere devi pensare a un approccio a livelli .

Prima di tutto, è più utilizzabile, confonde l'utente, ecc. Più campi contemporaneamente possono portare a maggiore confusione d'uso, frustrazione di digitazione, ecc. Forse l'utente si sente frustrato e questo si traduce in un uso meno complesso password (teorico in questo caso, ma UX è molto importante per convincere le persone a giocare bene con la sicurezza). C'è un vantaggio UX nel dover passare attraverso meno pagine. Mantenere i flussi ben compresi e un design uniforme è anche importante per aiutare gli utenti ad identificare il phishing - se le cose cambiano continuamente o sono diverse l'utente può essere confuso.

Sarei più preoccupato di ciò che sta succedendo su e giù nel resto del mio stack in questo caso. Cos'altro, oltre al nome utente, viene utilizzato per identificare l'utente? Ci sono cookie del browser, impronte digitali del browser, ecc. Se tutte queste cose vengono prese in considerazione solo per un utente autenticato, è possibile che si desideri proibire un'azione ad alto rischio fino a dopo l'autenticazione. Se hai una ragionevole certezza dell'identità dell'utente, potrebbe non avere un rischio tanto bilanciato con il lato UX.

La mia ipotesi sarebbe che, in generale, quando gli sviluppatori fanno questa scelta non è necessariamente con gli obiettivi di sicurezza o di sicurezza in mente. Potrebbe essere più facile per il loro flusso di utenti o help desk fornire questi collegamenti piuttosto che dare istruzioni che includono l'accesso e quindi la navigazione da qualche parte. Potrebbe anche avere senso dal punto di vista degli sviluppatori segmentare ogni funzione come questa.

In genere mi piacerebbe vedere un'autenticazione corretta e quindi richiedere la ri-autenticazione per una modifica della password. Penso che questo fornisce anche più compartimentalizzazione (rimuove l'identità dalla foto) che probabilmente porterebbe a bug meno legati alla sicurezza; stai anche limitando il privilegio solo agli utenti già autenticati. Sono d'accordo con alcune altre risposte che c'è un rischio di blocco / DoS con l'inserimento di questa funzione prima di un'autenticazione iniziale.

Da un punto di vista della sicurezza, questo dovrebbe andare bene a patto che la pagina protegga contro l'enumerazione degli utenti e la supposizione della password.

Dovrebbe convalidare la vecchia combinazione di ID utente e password nel suo insieme e non informare in modo specifico l'utente se l'ID utente non esiste, dovrebbe solo generare un messaggio di errore generico:

Your current user ID and password combination was incorrect. Your password was not changed.

Dopo un piccolo numero di combinazioni errate di ID utente e password rispetto a un nome utente, è necessario limitare le risposte per rallentare qualsiasi attacco indovinatore di password, rendendo l'attacco impossibile. Deve anche farlo per gli ID utente non validi, in modo da non perdere le informazioni di temporizzazione sul fatto che l'ID utente sia correlato a un account valido o meno.

Un vantaggio di un modulo che richiede la password esistente è che questo protegge intrinsecamente contro CSRF. Qualsiasi dominio esterno che tentasse tale attacco non sarebbe in grado di fornire una password corrente valida. Questo è menzionato nel foglio Cheat di prevenzione dei falsi siti di cross-site OWASP (CSRF) as Riautenticazione Challenge-Response .

Gli unici svantaggi potrebbero essere a livello di interfaccia utente. Dato che il browser bloccherà i campi della password in caso di mancata convalida sul lato server, l'utente dovrà inserire nuovamente la password corrente e quella nuova due volte.