Un sito web dovrebbe limitare i caratteri che possono essere inseriti nei suoi campi?

Il tuo approccio, se usato correttamente, ti proteggerà da due attacchi molto comuni: SQL injection e XSS. Ed escaping / encoding / prepared statements sono sicuramente un must-have e la tua principale linea di difesa.

Tuttavia, come menzioni specificamente le caselle di ricerca, il tuo approccio potrebbe, ad esempio, non catturare attacchi SQL con caratteri jolly (vedi qui e qui ), che potrebbe essere catturato dalla convalida dell'input (lato server, ovviamente non dovresti farlo con JavaScript sul lato client).

Il tuo approccio non colpirà anche i bug di sicurezza nel tuo codice. Quando il tuo codice base diventa abbastanza grande, la probabilità che tu dimentichi la codifica corretta in un solo posto aumenta, quindi avere una protezione aggiuntiva - sotto forma di validazione dell'input sul lato server - contro di esso non è una cattiva idea.

Non è male nemmeno da un punto di vista dell'esperienza utente (se un utente inserisce dati non validi, è bene riportarli a loro, in modo che sappiano cosa è andato storto e ora può inserire dati validi).

Il rovescio della medaglia è che è molto più lavoro. Devi effettivamente pensare a quale input dovrebbe essere consentito e cosa non dovrebbe, perché come hai detto, se filtri troppo, potrebbe limitare gli utenti. Se non si desidera eseguire questo lavoro per ogni campo di input possibile, un firewall per applicazioni Web potrebbe essere un'alternativa.

Non dovresti fidarti del cliente. Scrivere Javascript per impedire l'inserimento dei caratteri non impedisce a nessuno di inviarli alla tua ricerca.

La tua routine di ricerca dovrebbe rimuovere i caratteri che non supporta e, quando si stampa di nuovo, dovrebbe mostrare ciò che effettivamente ha accettato, non ciò che è stato inviato.

Per campi generici in un modulo, considera l'aggiunta di una convalida sul lato client per un'esperienza utente più piacevole; Preferirei sapere prima di rispondere che non accetterai cifre non numeriche nel campo Numero di telefono. Ma se vado in giro con i controlli Javascript e invio il modulo comunque, il server back-end dovrebbe respingere definitivamente i miei dati non validi; non lasciarlo solo al Javascript per disinfettare l'input.

Inoltre, mentre è accettabile che la maggior parte dei campi accetti qualsiasi cosa l'utente possa inserire e ripeti altrove, deve essere preceduto da caratteri di escape per impedire lo scripting cross-site (ad esempio, l'utente non può impostarne il nome come <script src="..."> ). Alcuni campi hanno preoccupazioni aggiuntive; ad esempio, se consenti agli utenti di scegliere un nome utente univoco, l' equivalenza Unicode potrebbe consentire loro di scegliere una codifica univoca per il loro nome ciò nonostante appare identico al nome di un altro utente, consentendo la rappresentazione. La normalizzazione non è sufficiente, perché alcuni caratteri guardano come altri personaggi, consentendo comunque la rappresentazione. Leggi considerazioni sulla sicurezza Unicode per ulteriori informazioni al riguardo.

Modifica: il tuo collega ha ancora un punto. Il lato server non vive in isolamento. Se accetta input da un utente e poi mostra alcuni di questi input ad altri utenti in un secondo momento, non è sufficiente che il lato server sia a prova di proiettile contro gli input dodgy. Esiste un'intera categoria di problemi di sicurezza che accadono lato client, perché i dati memorizzati sul lato server esattamente così com'è e consegnati ciecamente ad altri client (che vengono poi attaccati o ingannati da esso). Sì , il lato server deve limitare i caratteri di input, se possono sfruttare o ingannare gli utenti quando vengono restituiti nuovamente.

Lettura consigliata:

• Domande frequenti sulla sicurezza Unicode
• UTR # 36: considerazioni sulla sicurezza Unicode
• UTS # 39: Meccanismi di sicurezza Unicode (in particolare rilevamento di script misti )

Dovresti attuare entrambe le misure e ecco perché.

Se limiti lo spazio dei caratteri che l'utente può inserire (a-zA-Z! @ # $% ^ & *) per esempio ci sono meno possibilità che un utente inconsapevole rovini e inserisca alcuni dati jank. Tuttavia, ciò solo arresta realmente gli utenti finali che cercano di utilizzare l'applicazione per immettere dati non validi. Il secondo passo, l'esecuzione di un'adeguata sanificazione e la codifica dei dati garantiranno che sei libero da XSS / SQLi e da altri potenziali attacchi.

Quindi usa entrambi. Limita l'accesso degli utenti per impedire agli utenti finali che non conoscono meglio e disinfettano i dati per fermare quelli che sono un po 'più intelligenti.

C'è un buon consiglio nelle risposte sopra, ma non sono sicuro che abbiano affrontato la parte principale della tua domanda, ad esempio limitando il numero / la dimensione dei dati di input.

Per ricapitolare ciò che è stato già dichiarato

• Utilizzare la convalida dell'input lato client e il feedback per migliorare l'esperienza dell'utente del client, ma NON fare affidamento su alcun lato client per motivi di sicurezza. Tutte le misure sul lato client sono facilmente sconfitte. Il lato client è per il client e dovrebbe essere focalizzato sul client

• Effettua tutti i controlli di sicurezza, la convalida dei dati, l'igienizzazione dei dati ecc. sul lato server. Supponiamo che i dati forniti siano ostili e non possano essere considerati attendibili. Utilizza le soluzioni note ben collaudate, laddove possibile, piuttosto che reinventare la ruota e provare a dare un feedback all'utente se non permetti qualcosa in modo che sappiano cosa sta accadendo e possa ricostruire il loro input

Per quanto riguarda la domanda sulla limitazione della quantità di dati e quali dati sono consentiti e ciò che ritengo sia un'interpretazione inaccurata del concetto di essere liberale con ciò che accetti e conservatore con quello che fai suggerirei

• Non ha senso accettare dati che non puoi usare. Ciò che puoi utilizzare dipenderà dai limiti dei componenti che compongono la tua applicazione (database, codifiche dei caratteri supportati, limiti massimi del buffer ecc.)

• Non ha senso accettare i dati troppo a lungo per adattarli a qualsiasi uso tu abbia per questo, vale a dire accettare campi di dati più lunghi della lunghezza del campo del tuo database è inutile

• Considera il calo di prestazioni associato a dati di input estremamente lunghi. Ad esempio, se si tratta di una stringa di ricerca, esiste un limite al quale le prestazioni o le risorse utilizzate da query estremamente lunghe hanno un impatto negativo sul sistema o finiscono per restituire risultati inutilizzabili?

• Esiste il rischio che lunghezze di input illimitate possano provocare vulnerabilità di buffer overflow? TUTTI i componenti (librerie, sistemi esterni, database ecc.) Sono in grado di gestire lunghezze arbitrarie dei dati di input o si arrestano in modo anomalo, eseguono troncamenti inaspettati ecc.

Essere liberale in ciò che accetti non significa che devi usare tutto ciò che accetti. Significa davvero non solo fallire o crash. Significa fornire feedback all'utente perché non è possibile gestire l'input e rilevare i guasti in modo che siano gestiti con garbo. Non ha senso sostenere che si dovrebbe accettare tutto per una buona esperienza utente se non è possibile utilizzare ciò che viene fornito o gestirlo in maniera affidabile. Tuttavia, non si devono rilasciare caratteri in modo silenzioso o troncare input senza informare l'utente dei motivi o dei limiti. Gli utenti si sentono frustrati solo quando non è chiaro cosa sia e cosa non sia accettabile - forniscono informazioni chiare in modo che le loro aspettative corrispondano alle tue capacità e ci saranno molti meno utenti frustrati.

Da un puro punto di vista della sicurezza il tuo approccio è corretto. L'interfaccia web (html + javascript + qualunque ...) è solo un client per il tuo server HTTP. In altre parole, chiunque può fare richieste passando la sicurezza del cliente. Quindi la sicurezza a quel livello non ha praticamente alcuna sicurezza.

Da un punto di vista della GUI potrebbe essere una buona idea limitare i caratteri con javascript o altro. Ad es .: se il tuo campo dovrebbe avere un'età non c'è motivo di accettare caratteri alfabetici. Almeno previeni problemi sintattici dagli utenti. Se ben progettato, può rappresentare un grande vantaggio per la GUI (feedback rapido per l'utente) e per il server (evita richieste che restituiscono errori di convalida).