Non capisco perché la convalida lato client sia un potenziale rischio per la sicurezza o più un rischio per la sicurezza rispetto alla convalida lato server? Qualcuno può darmi qualche scenario?Perché la convalida lato client rappresenta un rischio per la sicurezza rispetto alla convalida lato server?
Idealmente si farebbe lato client e server e mai uno o l'altro. Se prendiamo in considerazione questi 3 scenari, entrambi sono l'unico modo sicuro e intuitivo per farlo:
Lato client Solo: Come accennato, non ci vuole molto per aggirare queste convalide se qualcuno vuole inviare dati non validi sul server (ad esempio SQL injection). NoScript non eseguirà il codice di convalida javascript e alcuni browser consentono all'utente di modificare attivamente tutti i javascript e html caricati, in modo che un utente possa sganciare il javascript di convalida dai controlli.
Solo lato server: questo è più sicuro del client solo da un lungo tiro, ma riduce la facilità d'uso. Devono inviare il loro modulo al server, farlo convalidare e ricevere la pagina di errore indietro dicendo che un campo particolare non era valido. La cosa fastidiosa è che se uno di questi campi fosse un campo password, i loro valori non vengono ripopolati di default. Ad esempio, diciamo che l'utente non ha inserito correttamente un numero di telefono in un modulo di creazione dell'account. Quando il server restituisce la pagina su come il numero di telefono è sbagliato, l'utente lo vedrà, correggerà il numero di telefono e premerà di nuovo invio, solo per ricevere un'altra pagina di errore su non aver inserito una password (e inserirla di nuovo nel secondo casella di testo) anche se questo non era il problema iniziale.
Lato client e server: si ottiene la sicurezza della convalida lato server, qualcosa a cui l'utente è costretto a interferire e la facilità d'uso della convalida dell'input senza dover inviare la pagina (se si convalida semplicemente javascript locale o AJAX).
Se fosse necessario sceglierne uno, il lato server sarebbe la strada da percorrere. Ma non dovresti mai scegliere l'uno o l'altro.
Grazie per la spiegazione, ora ha molto più senso. – Xaisoft
Era una domanda che avevo a scuola quando ho iniziato ad imparare le tecnologie lato server. Riguarda il quadro generale delle cose. –
Se si esegue la convalida solo sul lato client, qualcuno può disabilitare javascript (o modificare il codice js, con firebug, ad esempio). Quindi, tutte le convalide fatte in js sarebbero inutili e l'utente può inserire dati non validi nel proprio sistema.
Suppongo tu stia parlando di uno scenario web?
Se si sta eseguendo la convalida lato client con Javascript, cosa succede se l'utente ha JavaScript disabilitato? Quindi possono inviare dati al server che non è stato convalidato.
Se fossero subdoli, potrebbero persino inviare i dati direttamente al server (ignorando completamente la pagina).
Se si esegue la convalida lato server, oltre o al posto della convalida lato client, si ha un'ulteriore opportunità di difendersi da questi scenari.
Utilizzando vari strumenti, ad esempio Fiddler, Noscript, Web Developer, ecc., È possibile disabilitare la convalida javascript sul lato client e modificare i dati inviati al server. A seconda del tipo di dati e del comportamento del server, è possibile avviare un attacco SQL injection, tentare di compromettere la sicurezza del server o semplicemente archiviare dati fasulli.
Un esempio leggero: supponiamo di avere una convalida sul lato client per garantire che il codice postale sia 5 cifre o 5 + 4 cifre. Se disattivo lo script sul lato client, potrei lasciare il mio valore a 24 cifre in posizione. Se il tuo server non controlla ulteriormente il valore e il database è in grado di memorizzare tutte le 24 cifre, allora ho salvato i dati falsi.
Grazie per avermi parlato di questi strumenti. – Xaisoft
In realtà, esiste un enorme vantaggio in termini di sicurezza per la convalida lato client (in combinazione con la convalida lato server). Se si convalida con attenzione sul client, TUTTO il traffico proveniente dal server dovrebbe essere pulito. Tranne gli attaccanti. Ciò rende possibile un rilevamento degli attacchi lato server molto migliore. Nel grande schema di cose, questa è probabilmente la cosa più importante che potresti fare per proteggere le tue applicazioni. Vedere IntrusionDetector di OWASP ESAPI o AppSensor di OWASP per ulteriori informazioni.
Oh, e ovviamente se l'attacco inizia e finisce nel client, come l'XSS basato su DOM, allora dovrai convalidare e codificare sul lato client.
Vedo il punto, ma probabilmente dovresti chiarire che stai discutendo per la convalida lato client * oltre alla * convalida lato server. –
Grazie, aggiornato. –
Se la convalida è client-side, non lo si sta convalidando, il client è. Perché dovresti fidarti del client per convalidare i propri dati se la sicurezza è un problema? – mquander
Duplicati: http://stackoverflow.com/questions/3483514/why-client-side-validation-is-not-enough, http://stackoverflow.com/questions/1125772/should-you-do-validation-on -the-server-side – NullUserException
La convalida lato client non è una convalida: è solo zucchero UI. – seanb