Diciamo che stiamo creando un modulo di registrazione per alcuni siti web. So che se i campi di input non sono disinfettati, può verificarsi l'iniezione SQL. Ma diciamo che tutti i campi sono sterilizzati correttamente.
C'è qualche vantaggio nell'usare nomi utente alfanumerici? O è altrettanto buono per consentire qualsiasi simbolo?
Se consenti una qualsiasi sequenza di byte come nome utente, otterrai molti possibili problemi che gli utenti potrebbero abusare e altri problemi:
Per unicode, la stessa sequenza di caratteri può essere rappresentata come sequenze di byte diverse. Dovrai eseguire la normalizzazione Unicode per ottenere almeno una certa sicurezza contro la possibilità che le persone possano registrare un'altra rappresentazione in sequenza di byte per un nome utente.
Gli utenti possono scegliere personaggi dall'aspetto simile (ad esempio utilizzare due spazi anziché uno, ecc.) per ingannare le persone facendogli credere che si tratti di un altro account.
Gli utenti possono includere il carattere / all'interno del loro nome e modificare i collegamenti alle pagine relative al proprio account (ad esempio, si assegnano gli URL degli account a http://example.com/user/username e il codice si divide in / ).
La maggior parte dei siti guida l'approccio che assegnano due valori per un utente: in primo luogo, un "ID tecnico", che è alfanumerico e un secondo "nome completo", che può contenere spazi e altri simboli. L'ID alfanumerico deve essere univoco e il "nome completo" può contenere duplicati sul tuo sito.
Se sei preoccupato che un campo di testo venga abusato per eseguire l'iniezione SQL, allora l'input dei servizi igienici non è la soluzione corretta da cercare.
Se il campo di testo era completamente libero, allora ogni carattere che poteva essere utilizzato per l'iniezione SQL sarebbe un input valido. Se si tenta di evitare l'iniezione SQL disinfettando gli input, si finisce per rifiutare input validi. In altre parole, potresti aver evitato l'SQL injection, ma l'hai fatto introducendo un bug aggiuntivo non risolvendolo. Dal punto di vista dell'utente, ci sono almeno tanti casi di input validi che non funzionano come prima, forse anche più casi di prima.
La soluzione corretta per evitare l'iniezione SQL consiste nell'utilizzare espressioni di escape o parametrizzate (che evitano l'iniezione su un livello dello stack del protocollo spostando la responsabilità su un livello inferiore).
Se esegui correttamente l'escape in tutte le posizioni, non c'è alcun motivo tecnico per cui non sarebbe possibile lasciare che il campo del nome utente sia un campo di testo libero.
C'è una domanda diversa su quali caratteri autorizzare nei nomi utente. Sebbene sia tecnicamente possibile supportare nomi utente in forma libera, non è necessariamente una buona idea. Esistono validi argomenti per limitare l'insieme di caratteri consentiti nei nomi utente, ma questi argomenti non hanno nulla a che fare con l'iniezione SQL.
Limitare i nomi utente solo ai caratteri ASCII è utile se hanno bisogno di essere comunicati attraverso canali in cui non si è sicuri della codifica.
Limitare i nomi utente ai personaggi che si trovano nella stessa posizione su diversi layout di tastiera è utile se si lavora in un ambiente internazionale. Ma non imporre tali limitazioni nel software, perché la serie di layout di tastiera utilizzata da ciascun utente è diversa.
Prevenire nomi utente visivamente identici può essere una buona idea in sistemi in cui è importante essere in grado di riconoscere un nome utente. Questo significa nessun carattere non stampabile. E se due caratteri sembrano uguali, ne consente uno solo (raramente si tratta di un problema se si utilizzano solo caratteri ASCII). E gli spazi non possono essere permessi all'inizio e alla fine del nome utente, né possono essere consentiti due spazi uno accanto all'altro.
E ricorda che limitare i nomi utente consentiti non è un sostituto per generare SQL in modo sicuro.
Per i campi nomi utente non è necessario utilizzare solo alfanumerici ma devi fare attenzione alla lista nera di alcuni caratteri speciali come "e" sulle convalide degli input.
Per i campi Password è necessario utilizzare alfanumerico e alcuni caratteri speciali come @ e # per rendere la nostra password così strong.
Ad esempio dovrebbe essere in Abc @ 123 # e non dovrebbe essere in abcd, perché se usi una password debole è possibile per un utente malintenzionato dirottare usando l'attacco Brute Force
Il nome utente può essere: abc123, ma deve essere convalidato.
Leggi altre domande sui tag user-names registration