Perché abbiamo bisogno sia della convalida lato client che lato server?

Question

L'argomento per l'utilizzo della convalida lato client (JavaScript) e della convalida lato server utilizzando un validatore è questo: Se il browser client non supporta JavaScript, l'utente non può utilizzare la convalida lato client.

La mia domanda è quanto è valido questo argomento nella pratica? In teoria ha senso, ma in pratica, se JavaScript è disabilitato nel browser, la maggior parte delle funzionalità del sito Web non funzionerà. L'utente probabilmente non può nemmeno caricare la pagina senza JavaScript, per non parlare di inviare un modulo.

Answer 1

La convalida lato client impedisce al cliente di andare "ma ho inserito tutto questo e non mi ha detto nulla!". Non è effettivamente obbligatorio, e in realtà, la convalida lato client è una cosa molto nuova (leggi: 5 anni o meno). In pratica, tutto ciò che fa è impedire al client (con JS abilitato) di sapere se il modulo è ok prima di ricaricare una pagina. Se AJAX è in gioco, è diverso: consente di risparmiare larghezza di banda e di fornire all'utente feedback prima dell'invio. Infine, se stai costruendo applicazioni di scambio peer-to-peer strettamente client-side (pensi giochi), ti consigliamo di convalidare sul lato client la convalida dei client.

La convalida lato server è fondamentale anche per il fatto che la convalida lato client può essere completamente aggirata disattivando JavaScript. In un certo senso, la validazione basata su JS è una convenienza e un miglioramento estetico/cosmetico e dovrebbe essere invocato non. Inoltre, è banale modificare la sorgente di una pagina localmente per disabilitare o bypassare anche la più complessa convalida JS.

Cosa potrebbe fare un utente se non si convalida sul lato server? Qualunque cosa, a seconda di come usi i loro dati. Puoi consentire agli utenti di eliminare interi database (o, peggio, di farli fuoriuscire), modificare ciò che preferiscono (o peggio, leggere tutto quello che vogliono. I difetti di attraversamento delle directory sono punti di accesso estremamente comuni per le persone cattive) ed elevare i loro privilegi a piacimento. Vuoi correre questo rischio? Non convalidare l'input dell'utente è come fidarsi delle persone e non installare i lucchetti sulla tua casa.

Answer 2

La convalida deve essere eseguita sempre dal lato server: non si può mai fidarsi della convalida sul lato client.

La convalida lato client è sempre nel senso di fornire una migliore esperienza utente (UX), quindi l'utente non deve inviare e ricaricare una pagina semplicemente perché un valore in un modulo non è valido - rende le cose più dinamiche.

Poiché non è nemmeno necessario un browser per effettuare richieste, indipendentemente dal fatto che il proprio sito Web si basi su JS per funzionare correttamente, è necessario eseguire la convalida sul lato server e disinfettare tutti gli input dell'utente nel caso in cui ci si preoccupi di non avere i database pasticciati .

Ora spetta a te decidere se fornire un'interfaccia utente con suggerimenti di convalida dinamici sul lato client o meno.

Answer 3

La convalida lato client è una soluzione per moduli altamente interattivi con convalida sul campo, ma non impedisce a un utente malintenzionato di iniettare e inviare dati formattati non validi al server. È importante che lo script sul lato server convalidi tutto ciò che l'utente sta facendo, altrimenti esporrai il tuo sito a attacchi SQL injection, attacchi XSS, utenti che fanno cose che non dovrebbero ecc.

Answer 4

Proteggi sempre i tuoi ingressi su il server. Non si tratta sempre di utenti che hanno JavaScript disabilitato ma anche che potrebbero rompere il server.

Per esempio, se un sito ha un controllo di massima lunghezza JavaScript su un <input>, un utente può potrebbe disabilitare tale controllo, inviando in tal modo più dati rispetto a server e/o il database è in attesa. Questo potrebbe sovraccaricare il server di un POST di grandi dimensioni che occupa un thread del server per un lungo periodo, potrebbe esporre un punto debole nel database, ad esempio violando un vincolo del database potenzialmente esponendo dettagli su qualsiasi informazione di persistenza. Peggio ancora, se non c'è alcun vincolo un utente potrebbe essere in grado di eseguire attacchi di iniezione.

Un altro esempio è qualcuno che utilizza uno strumento HTTP esterno per inviare richieste al server, ignorando completamente qualsiasi JavaScript. Io uso lo Advanced REST Client per Chrome tutto il tempo in sviluppo per testare le API JSON.

client validazione lato tramite JavaScript è solo un modo di fornire un più rapido feedback per una persona che utilizza il sito di qualsiasi informazione sulla loro interazione con il sito. Nella comunicazione client-server tradizionale dovrebbe essere non essere l'unica convalida per i motivi illustrati sopra.

Answer 5

Se un utente ha disabilitato JavaScript è un problema di se stesso e ha deciso solo per disabilitare il javascript per un motivo ... Per questo, quando si fa un sito web è necessario avere sempre a mente che il vostro sito web deve essere valido per utenti con e senza javascript. La validazione lato sia è necessario per una serie di motivi, alcuni di loro sono:

• utente ha disattivato JavaScript
• Un utente di male nel fine ha rimosso il javascript per poter sfruttare il sistema
• con JavaScript convalida riducendo il traffico di dati tra il sito Web e il client.
• E, naturalmente, con la convalida del server è assicurarsi che una volta per tutte che i dati siano corretti

E 'possibile avere un sito web che utilizza JavaScript e tecnologie "vecchi" per essere valido per ogni utente e ogni browser