È possibile raccogliere un insieme di nomi utente validi interagendo con il meccanismo di autenticazione dell’applicazione. Questo test sarà utile per i test di forza bruta, in cui il tester verifica se, dato un nome utente valido, è possibile trovare la password corrispondente.
Spesso, le applicazioni web rivelano se un nome utente esiste nel sistema, sia come conseguenza di una errata configurazione sia come decisione di progettazione. Ad esempio, a volte, quando inviamo credenziali errate, riceviamo un messaggio che indica che il nome utente è presente nel sistema o che la password fornita è errata. Le informazioni ottenute possono essere utilizzate da un attaccante per ottenere un elenco di utenti nel sistema. Queste informazioni possono essere utilizzate per attaccare l’applicazione web, ad esempio, tramite un attacco di forza bruta o un attacco con nome utente e password predefiniti.
Correzione suggerita:
La finestra di dialogo “forgot my email” dovrebbe comportarsi allo stesso modo, sia che l’email sia corretta o errata.
Abilita Admin - Impostazioni - Login - nascondi email già in uso
nascondi email già in uso
Non informare gli utenti che un account esiste con un dato indirizzo email durante la registrazione o durante il flusso di recupero password. Richiedi l’email completa per le richieste di ‘password dimenticata’.
Avendo letto in giro, questo è successo alcune volte prima. Penso che uno degli altri punti importanti sia che abbiamo un limite di frequenza nel tentativo di accedere:
Grazie a entrambi. Mi sono imbattuto in questo bug in modo organico su meta.discourse.org e non ero a conoscenza di quell’impostazione, ma è bene sapere che la correzione è già stata codificata e la patch dovrebbe essere molto semplice. Per soddisfare le best practice OWASP, tale impostazione dovrebbe essere sempre abilitata. Non so perché un amministratore vorrebbe disabilitarla, poiché farlo rappresenta una vulnerabilità di sicurezza e privacy totalmente non necessaria che viola esplicitamente gli standard di best practice del settore. Se c’è qualche motivo per preservare questa opzione per installazioni legacy che non riesco a capire, allora dovrebbe essere aggiunto un avviso per indicare che la configurazione corrente viola le best practice standard del settore e raccomandare invece la configurazione conforme.
Grazie per aver collegato questo thread. @awesomerobot ha diritto alla propria opinione, ma sta anche sfidando sfacciatamente le best practice standard del settore e insistendo sul fatto che un bug ben noto, spesso segnalato ed esplicitamente codificato sia in qualche modo “non un bug”, e non trovo la loro opinione molto convincente rispetto alle best practice standard del settore pubblicate.
Se non altro, il valore predefinito dovrebbe riflettere la configurazione più sicura e dovrebbe esserci un’indicazione per informare gli amministratori alle prime armi che la disabilitazione di questa opzione costituisce una vulnerabilità di sicurezza e privacy deliberata e non necessaria sul loro forum. Un link alla voce OWASP o qualcosa del genere.
Qualcuno può illuminarmi sullo scenario in cui potrebbe essere preferibile avere questa opzione disabilitata? Sinceramente non so perché questa sia una questione controversa e vorrei sapere se mi sfugge qualche caso d’uso che annulli il modello di sicurezza opt-in implementato con questa impostazione. Se tale scenario non può essere suggerito, allora questa impostazione dovrebbe essere sempre abilitata e quindi non dovrebbe essere affatto un’impostazione.
Penso che, al momento, tutto funzioni come previsto, quindi non possiamo davvero classificarlo come un Bug. Tuttavia, rivalutiamo regolarmente le nostre impostazioni predefinite e tu hai sollevato alcuni punti interessanti che vale la pena considerare.
Lo sposterò in UX in modo che la conversazione possa continuare lì.
Semplicemente… le persone non sono brave a ricordare quale indirizzo email hanno usato per creare un account e contatteranno gli amministratori per risolvere i problemi.
Questo è simile a imponi secondo fattore o lunghezza minima password — Penso che la raccomandazione generale sia di richiedere sempre un secondo fattore, e le raccomandazioni sulla lunghezza minima della password ora sembrano essere più alte del nostro attuale default per gli utenti normali… ma c’è anche un divario tra le raccomandazioni di sicurezza e le competenze informatiche medie.
Non sono fortemente contrario a cambiare i default, ma vale la pena notare che possono influire sull’usabilità.
Grazie a tutti per i vostri preziosi contributi e prospettive su questo bug. Per me, questo è molto semplice e per niente complicato: esiste un bug ben noto in Discourse che è stato ripetutamente segnalato da amministratori e professionisti della sicurezza come me, e viene trattato come una funzionalità invece che come una vulnerabilità di sicurezza: NIST: CWE-200: Esposizione di informazioni sensibili a un attore non autorizzato.
Giustificare questa configurazione predefinita non sicura che viola le migliori pratiche standard del settore citando una situazione ipotetica in cui un amministratore del forum è sommerso dalle richieste degli utenti su quali email hanno utilizzato per l’iscrizione non ha senso, poiché l’utilizzo della pagina “password dimenticata” non richiederebbe questa interazione amministrativa indipendentemente dalla configurazione di questa impostazione: se è abilitata l’impostazione più sicura e conforme agli standard, l’utente controllerà semplicemente la/le propria/e email nella finestra di dialogo “dimentica la mia email” e vedrà se quell’indirizzo ha ricevuto o meno un’email di reimpostazione della password, esattamente come spiegato dalla finestra di dialogo e come è comune in tutte le applicazioni web moderne, rispettose della privacy e conformi agli standard. Inoltre, giustificare questa violazione sulla premessa che altri siti potrebbero anche violare le migliori pratiche non è un argomento logico o convincente dal punto di vista della sicurezza e della protezione dei dati. Faccio fatica a capire perché stiamo dando agli amministratori la “funzionalità” di rendere la loro installazione di Discourse marginalmente meno sicura e conforme agli standard senza alcun chiaro beneficio.
Tuttavia, ho fatto il lavoro che mi hai prescritto @sam:
1. Google: non consente l’enumerazione degli utenti.
2. YouTube: non consente l’enumerazione degli utenti (perché utilizza l’accesso Google e Google non consente l’enumerazione degli utenti).
3. Facebook: consente ufficialmente l’enumerazione degli utenti tramite la pagina “trova un account”/“password dimenticata” solo se l’utente ha deliberatamente contrassegnato la propria email/numero di telefono come pubblico, e tuttavia ha fatto trapelare famosamente i dati di 500 milioni di utenti attraverso questo tipo di vulnerabilità, e ha pagato migliaia di dollari a revisori di sicurezza che hanno scoperto che il loro rate limiting e le regole “solo se esplicitamente contrassegnato come pubblico” non venivano rispettate internamente.
4. Instagram: consente l’enumerazione degli utenti (e ne ha pagato le conseguenze). Questo è un hack diverso da quello che ho menzionato per Facebook.
5. X (si prega di essere rispettosi riguardo al dead-naming su questo forum): consente l’enumerazione degli utenti tramite la pagina password dimenticata, ma implementa il rate limiting e alcuni altri ostacoli facilmente aggirabili e ha comunque compromesso famosamente i numeri di telefono dei propri utenti attraverso un bug nella loro implementazione del rate limiting e delle protezioni per la privacy dei dati.
6. Baidu: consente l’enumerazione degli utenti nella pagina email dimenticata e implementa captcha (e forse rate limiting? Il mio cinese è scarso). Interessante, il processo di recupero richiede l’apertura di un ricorso al team di amministrazione, piuttosto che una semplice email di recupero. Molto tipico del controllo centrale del PCC.
7. Wikipedia: non consente l’enumerazione degli utenti.
8. Yahoo: Consente l’enumerazione degli utenti tramite la pagina password dimenticata, ma implementa rate limiting e captcha. Non ho trovato esempi di Yahoo coinvolto in controversie o che abbia pagato hacker che sfruttano questo bug, ma è davvero difficile cercare Yahoo su qualsiasi motore di ricerca per ovvie ragioni.
9. Yandex: consente l’enumerazione degli utenti nella pagina di accesso, implementa captcha e domanda di sicurezza nella pagina email dimenticata.
10. Whatsapp: non consente l’enumerazione degli utenti. L’accesso al PC avviene tramite credenziali mobili. Le credenziali mobili sono legate al tuo numero di telefono. Non esiste un pulsante di logout, né una pagina di accesso/email dimenticata.
11. XVideos: non consente l’enumerazione degli utenti.
12. PornHub: non consente l’enumerazione degli utenti.
13. Amazon (sito di e-commerce): consente l’enumerazione degli utenti tramite la pagina password dimenticata, in diretta violazione delle proprie raccomandazioni sulle best practice per il prodotto Amazon Web Services’ Cognito user pools. Non ho trovato esempi di Amazon coinvolto in controversie o che abbia pagato hacker che sfruttano questo bug, ma è davvero difficile cercare Amazon su qualsiasi motore di ricerca per ovvie ragioni.
14. Xnxx: non consente l’enumerazione degli utenti. Il sito principale non ha una vera e propria pagina di accesso e il sito “gold” non consente l’enumerazione degli utenti. Ho trovato una pagina di accesso defunct sulla versione mobile del sito normale, e semplicemente non ha la funzionalità “dimentica la mia email” (ed è anche apparentemente defunct, a favore del loro sito web “gold”).
15. Tik Tok: non consente l’enumerazione degli utenti. Impone MFA sulla pagina password dimenticata.
(21. Reddit: Non consente l’enumerazione degli utenti. Sono conformi alle migliori pratiche standard del settore.)
Dei primi 15 siti in quella lista, 8/15 NON consentono l’enumerazione degli utenti (o 9/16 se si include Reddit, e si aggiunge discutibilmente 0,5 per Facebook poiché consente solo l’enumerazione di informazioni che l’utente ha deliberatamente approvato di rendere pubbliche), e almeno 3/7 dei siti di quella lista che DO consentono l’enumerazione degli utenti hanno affrontato eventi di sicurezza critici a seguito di tale decisione.
È altrimenti banale verificare l’esistenza di account sui provider di identità email, quindi non c’è molto senso nell’includerli nell’elenco.
Nessuna delle altre piattaforme in quell’elenco è (potenzialmente) software self-hosted.
Non esiste una Piattaforma Discourse Centrale: gli amministratori del sito sono liberi di scegliere da soli.
Detto questo, sarei d’accordo nel dare una spinta agli amministratori del sito per scegliere buone impostazioni per impostazione predefinita.
Forse un interruttore che gli amministratori possono attivare (esito a suggerire di aggiungerlo alla procedura guidata) per semplificare il blocco di impostazioni come questa.
Non si applica a qualsiasi sito con una pagina di registrazione, non solo ai fornitori di servizi di posta elettronica? Capisco il tuo punto su come le pagine di registrazione siano un potenziale vettore per vulnerabilità simili di privacy e dati e quindi debbano essere protette, ma questa è una parte diversa del flusso di autenticazione dell’utente rispetto a quella di cui stiamo discutendo in questo argomento. In questo argomento, stiamo esaminando specificamente le fughe di dati dal dialogo “ho dimenticato la password”. Non fraintendermi: entrambi sono assolutamente importanti, richiedono un’attenta considerazione e necessitano di mitigazioni per prevenire vulnerabilità di privacy e dati. Di solito per i moduli di registrazione è richiesto un captcha, e per gli endpoint “ho dimenticato la password” si desidera avere la stessa risposta indipendentemente dal fatto che l’email sia valida o meno. Molti siti proteggono anche l’endpoint “ho dimenticato la password” con un captcha. Entrambi gli endpoint dovrebbero essere limitati nella frequenza di accesso.
Certamente non stavo cercando di essere disonesto. Non penso che sia accettabile non essere conformi perché anche altri siti non sono conformi sia una conclusione logicamente valida, stavo solo soddisfacendo la richiesta di Sam e per alleviare qualsiasi preoccupazione potesse avere fornendo la “prova” che cercava utilizzando il link che aveva fornito.
Incoraggio certamente la libertà dell’amministratore e non mi piace rendere la vita degli amministratori o degli utenti più difficile, ma non credo che i “pro” di questa impostazione superino i “contro” in nessuno scenario, e non c’è caso in cui un amministratore voglia realmente questa “funzionalità”. Proprio come non permettiamo a un amministratore di imporre una lunghezza massima della password, non dovremmo permettergli di degradare inutilmente e marginalmente la sicurezza del proprio forum consentendo questa vulnerabilità di enumerazione nel dialogo “ho dimenticato la password”. Penso che dovremmo semplicemente rimuovere del tutto l’opzione e costringere tutti a seguire il modo conforme agli standard. Onestamente non penso che la maggior parte degli amministratori se ne accorgerebbe o se ne curerebbe, ma renderebbe un endpoint esposto su Internet pubblico un po’ più sicuro su tutte le installazioni di Discourse. Se dobbiamo includere l’impostazione, allora dovrebbe essere nella posizione più sicura per impostazione predefinita, e la posizione meno sicura dovrebbe essere chiaramente demarcata in modo che gli amministratori novizi comprendano perché non è raccomandata. Penso che semplicemente rifattorizzare questa impostazione fuori dall’esistenza sia l’opzione migliore, però. Sarei felice di presentare una PR per questo.
Non credo che si possa guardare a nessuno dei due nel vuoto. Nel processo di registrazione di Discourse c’è un messaggio “Email has already been taken” (Email già in uso) ed è difficile vedere come farlo diversamente. Finché esisterà, è difficile capire quale sia il grosso problema con il messaggio “We found an account that matches” (Abbiamo trovato un account corrispondente) in particolare.
Suppongo che farebbe la differenza in un forum che consente solo l’autenticazione esterna.
Superato l’impulso di dissentire da te solo per il tuo stile, penso che nel merito tu abbia ragione nella misura in cui la tua posizione è che l’opzione predefinita dovrebbe essere quella più sicura, almeno quando viene utilizzata l’autenticazione esterna. Non sono ancora d’accordo sul fatto che non ci sia alcun posto per l’opzione meno sicura (il mio forum ha il processo di registrazione predefinito di Discourse, quindi non ho intenzione di cambiare l’opzione di reimpostazione della password).
Tra l’altro, ho riso del fatto che tu abbia lasciato al lettore il compito di indovinare dal contesto che XVideos e Xnxx (anche se non X) siano pornografici, ma ti sia preso la briga di spiegare che Amazon è un “sito di e-commerce”.
Serviva a distinguere Amazon.com da AWS. E visto che hai chiesto: AWS non consente l’enumerazione degli utenti.
Concordo sul fatto che devi considerare tutti i passaggi di un flusso di autenticazione utente e come funzionano insieme. È estremamente importante e una delle fonti più comuni di vulnerabilità di sicurezza. Se quel simile bug di enumerazione delle email nella pagina di registrazione che hai menzionato non è adeguatamente mitigato, allora dovrebbe assolutamente essere corretto indipendentemente dall’esito di questo argomento. Sarebbe un bug nell’implementazione di hide_email_address_taken. La discussione di quel potenziale bug/svista dovrebbe probabilmente avvenire in un argomento diverso (e probabilmente con un tag bug).
Solo per segnalare, con hide email address taken abilitato, non dà nemmeno quel messaggio durante la registrazione (cambia anche il messaggio di invito quando viene inserita un’email esistente).
Penso che una delle possibili complicazioni per invertire semplicemente l’impostazione predefinita sia che include anche il “richiedi email completa per il reset della password”, il che potrebbe complicare eccessivamente le cose (anche se probabilmente non è un blocco completo).
Esatto. Con nascondi indirizzo email già in uso abilitato è necessario inserire l’indirizzo email dell’account per il reimpostamento della password e non è possibile utilizzare solo il nome utente.
Suggerisco di rinominare hide_email_address_taken SiteSetting in prevent_password_recovery_by_username, e quindi di rifattorizzare il comportamento non conforme dall’app per tutti gli utenti. Ciò preservare la funzionalità di reimpostazione della password senza modifiche per tutte le installazioni, affrontando al contempo la vulnerabilità di enumerazione delle email. Sono uno sviluppatore esperto di RoR + javascript e sarei felice di implementare questa pull request; ho dato una rapida occhiata al codebase e posso vedere che non sarebbe una PR eccessivamente estesa.
Se rifattorizzare questa ‘funzionalità’ fino a farla scomparire non è davvero un’opzione, allora penso comunque che abbia senso separare questi due concetti correlati in voci SiteSetting separate.
)
