Devi limitare i possibili caratteri di un nome utente? [chiuso]

-4

Stavo guardando il sistema di accesso di Twitter e ho visto questo messaggio di errore quando cercavo di inserire un nome utente

Your username can only contain letters, numbers and '_'.

Twitter offre la possibilità di accedere tramite e-mail, telefono o nome utente. Quindi, quando compili il modulo di accesso, puoi inserire {email, password} o {username, password} per esempio.

Suppongo che questo messaggio di errore sia lì per impedire a un utente di scegliere un indirizzo email come nome utente.

Sarebbe un problema se il nome utente fosse anche un indirizzo email?

Suggerimento : cosa succede quando qualcuno usa un indirizzo email che non possiede come nome utente e quindi l'utente legittimo di questa email prova a creare un account ...

EDIT : credo che tutto ciò vada molto oltre la semplice esperienza dell'utente e possa essere un abuso come pratica anticoncorrenziale da parte di aziende malevoli. Vedi la mia risposta qui sotto per i dettagli.

EDIT2 : ecco un esempio. Crei un account con la seguente impostazione:

Riceverai quindi un messaggio di conferma solo per [email protected], che possiedi, e hai effettivamente bloccato Bill Gates dall'usare il suo indirizzo [email protected] per creare un account sul sito web.

Ripeti il processo per 1000 volte e impedirai a molti utenti di utilizzare il loro indirizzo preferito. Gli utenti che potrebbero decidere di non utilizzare il servizio a causa di una scarsa esperienza e la società perderebbe un sacco di soldi.

    
posta Gudradain 09.02.2016 - 20:20
fonte

1 risposta

2

C'è un motivo in più per limitare i caratteri di un nome utente piuttosto che per limitare i caratteri di una password. In pratica, il nome utente funge da identificatore di record in un sistema di accesso: è necessario utilizzare l'input per trovare l'hash della password nel sistema di accesso. Con le dichiarazioni di database preparate, questo non è davvero un problema, ma molti sistemi non usano istruzioni preparate - da qui il numero di attacchi di SQL injection che sono ancora possibili.

Se non stai usando istruzioni preparate, hai due opzioni. Innanzitutto, puoi passare attraverso l'input non modificato. Questa è una cattiva idea - considera un nome utente come ' or 1=1 -- - è valido, in teoria, ma se il tuo sistema di login usa una riga come select * from users where username=$username and password=hash($password) , hai appena creato un punto di iniezione SQL. Questo è più comune di quanto si spera.

In alternativa puoi disinfettare in modo coerente tutta la tua applicazione. Se scegli questo, devi assicurarti che ogni possibile modalità di accesso (sito web, applicazione mobile, API) utilizzi lo stesso processo di disinfezione. Potresti (e questo è un cattivo esempio - non usare in produzione) l'URL codifica tutti i caratteri nel nome utente, quindi lo stesso nome utente verrebbe memorizzato come %27+or+1%3D1+-- . Questo è leggermente migliore di quanto sopra, ma potrebbe portare a problemi inaspettati se ci sono problemi con il processo di sanificazione. Può persino cancellarli se lo desideri, ma poi diventa molto difficile collegare i report degli utenti con i loro record.

Inoltre tendi a stampare i nomi utente all'interno dell'applicazione in vari punti. Se hai autorizzato caratteri, avresti aperto la tua applicazione alle vulnerabilità XSS. Ciò non viene evitato a meno che non venga codificata l'output correttamente, ma il problema è che ciò che mostra nell'applicazione potrebbe non funzionare correttamente per l'accesso.

In termini di un indirizzo email come nome utente, in teoria va bene. Ma gli indirizzi e-mail sono perfettamente in grado di includere quasi tutti i problemi precedenti!

    
risposta data 09.02.2016 - 20:58
fonte

Leggi altre domande sui tag