Perché abbiamo bisogno della convalida lato client e lato server?

L’argomento relativo all’utilizzo della convalida lato client (JavaScript) e della convalida lato server tramite un validatore è questo: se il browser client non supporta JavaScript, l’utente non può utilizzare la convalida lato client.

La mia domanda è quanto è buono 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.

La convalida sul lato client evita solo che il cliente vada “ma ho riempito tutto questo e non mi ha detto niente!”. In realtà non è obbligatorio, e in realtà, la validazione 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), vorrai che la convalida sul lato client impedisca ai client di barare.

La convalida lato server è fondamentale anche perché la convalida lato client può essere completamente aggirata distriggersndo JavaScript. In un certo senso, la validazione basata su JS è una convenienza e un miglioramento estetico / estetico e non dovrebbe essere invocata. 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.

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

La convalida sul lato client è sempre nel senso di fornire una migliore User Experience (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 hai nemmeno bisogno di un browser per effettuare richieste, indipendentemente dal fatto che il tuo sito web si basi su JS per funzionare correttamente, avrai bisogno di una validazione sul lato server e di sterilizzare tutti gli input dell’utente nel caso ti interessi di non avere i tuoi database pwned.

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

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

Ad esempio, se un sito ha un controllo di lunghezza massima JavaScript su un , un utente può disabilitare tale controllo, inviando quindi più dati di quanto il server e / o il database non si aspettino. 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 il client REST avanzato per Chrome tutto il tempo in fase di sviluppo per testare le API JSON.

La convalida lato client tramite JavaScript è solo un modo per fornire un feedback più rapido a una persona che utilizza il sito di qualsiasi informazione sulla sua interazione con il sito. Nella comunicazione client-server tradizionale non dovrebbe essere l’unica validazione per le ragioni sopra delineate.

Se un utente ha disabilitato javascript è un problema di se stesso e ha deciso da solo di disabilitare il javascript per un motivo … Per questo, quando si crea un sito Web è necessario avere sempre presente che il proprio sito Web deve essere valido per gli utenti con e senza javascript. La convalida di entrambi i lati è necessaria per una serie di motivi, alcuni dei quali sono:

  • L’utente ha disabilitato javascript
  • Un utente malvagio ha rimosso il javascript per sfruttare il sistema
  • Con la convalida di javascript si riduce il traffico di dati tra il sito Web e il client.
  • E ovviamente con la convalida del server ci si assicura una volta per tutte che i dati siano corretti

È ansible che un sito Web che utilizza le tecnologie javascript e “precedenti” sia valido per ogni utente e browser.

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 di SQL injection, attacchi XSS, utenti che fanno cose che non dovrebbero, ecc.