Domanda:
La convalida del modello di input HTML5 è sufficiente (o addirittura pertinente) per la convalida lato client?
msanford
2017-09-19 18:43:50 UTC
view on stackexchange narkive permalink

Una caratteristica interessante di HTML5 è l'attributo <input pattern = "" / > , che consente al browser di convalidare il valore del campo di input rispetto a un'espressione regolare fornita dal sviluppatore.

Successivamente, questo si lega a ValidityState del campo che può quindi essere interrogato per il feedback UX, per evitare invii non validi e così via.

Il server implementa la stessa convalida delle precondizioni (così come XSRF).

Detto questo, questo modello di convalida lato client è maturo e adeguato o per qualche motivo è ancora desiderabile intercettare l'intero modulo e sottoporlo alla tradizionale convalida per campo prima di inviarlo?

_ "... questo modello di convalida lato client è maturo e adeguato ..." _ Dato che non si tratta di sicurezza ma di programmazione (vedi risposte) ... se la convalida HTML5 ha tutto ciò di cui hai bisogno, allora sì.Ovviamente se i browser devono essere compatibili con le funzionalità richieste dal supporto ...
@AdrianoRepetti In effetti, ci sono ovvie preoccupazioni sia dal punto di vista esperienziale che di sviluppo (principalmente mantenimento).Il mio obiettivo nel chiedere qui era di testare il mio ragionamento sottostante, che è felicemente congruente con questa comunità.(Hai senza dubbio visto posti che faranno cose stupide come impedire di incollare un campo della password "per motivi di sicurezza". Questo, come un secondo ciclo di convalida, è chiaramente inutile.)
@ms sì, non volevo dire che la domanda è fuori tema ma per quanto riguarda la sicurezza hai già delle risposte e i miei 2 centesimi sono per la parte "matura e adeguata" della convalida HTML5
Sì, è sufficiente per l'esperienza utente, no non è sufficiente per l'esperienza di sicurezza.
Cinque risposte:
#1
+110
Anders
2017-09-19 18:50:51 UTC
view on stackexchange narkive permalink

Dal punto di vista della sicurezza, è necessario riconvalidare tutto sul server. Questo sarà sempre il caso, non importa quanto siano belle e avanzate le funzionalità HTML5. Semplicemente non puoi fidarti del cliente. Non hai idea se seguirà o meno le regole HTML5. Non sai nemmeno se si tratta di un browser.

Quindi dovresti convalidare l'intero modulo con il tuo lato client JS prima di inviarlo, anche se utilizzi le funzionalità HTML5? Dal punto di vista della sicurezza non importa. La convalida lato client ha comunque valore di sicurezza zero - vedi sopra - quindi dal punto di vista della sicurezza potresti anche non preoccuparti di farlo affatto.

La convalida lato client riguarda esclusivamente l'esperienza dell'utente. Se la tua convalida JS o HTML5 integrato crea la migliore UX è una domanda interessante, ma non è in argomento qui.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/65978/discussion-on-answer-by-anders-is-html5-input-pattern-validation-sufficient-or).
#2
+16
Andy
2017-09-20 20:27:11 UTC
view on stackexchange narkive permalink

Una spiegazione con codice e screenshot

Le risposte fornite sono ottime. Ma volevo illustrarlo con alcuni codici / screenshot.

La conclusione è che qualsiasi cosa lato client può essere manipolata (disabilitata / completamente eliminata / aggirata o modificata) dall'utente finale. Quindi qualsiasi tipo di "convalida lato client" è totalmente inutile dal punto di vista della sicurezza. Devi sempre convalidare le cose lato server.

Supponiamo che tu abbia un modulo HTML come questo:

  <form method = "post" action = "index.php" > <input type = "email" name = "emailAddress" required> <button type = "submit" >Submit form< / button>< / form>  

Questo sta chiedendo un indirizzo email ( ), dicendo che è un campo obbligatorio (attributo richiesto ).

Se provo a inviare qualcosa che è vuoto o non è un indirizzo email, verrà visualizzato un errore, ad es.

enter image description here

Perché è inutile dal punto di vista della sicurezza? Tutto ciò che l'utente deve fare è manipolare l'HTML . Possono farlo salvando una copia della pagina web, modificandola e riaprendola. Oppure possono utilizzare gli strumenti per sviluppatori nel browser per modificare il markup. Possono farlo perché è codice lato client ed è sotto il loro controllo .

Supponiamo che modifico il markup del modulo in questo:

  <form method = "post" action = "index.php" > <input type = "text" name = "emailAddress" > <button type = "submit" >Submit formAiliqaskiflaskiflt / buttonAiliqrecode  button > Ora sto dicendo che il campo  emailAddress  è di tipo  text  (cioè non  email ) e non è un campo obbligatorio (rimosso  richiesto  attributo). 

Quindi posso inviarlo al server. La stringa di testo "andy" ovviamente non è un indirizzo email valido. Ma poiché non abbiamo (ancora) una convalida lato server, sarà abbastanza felicemente inviato al server e quindi se il codice PHP usasse $ _POST ['emailAddress'] avrebbe "andy" come suo dati.

enter image description here

Potrei anche inviare il modulo senza dati, nel qual caso l'applicazione, senza alcuna convalida lato server, avrebbe una stringa vuota nella variabile $_POST['emailAddress'”.

Ciò era possibile solo perché io, come utente finale, potevo manipolare il codice lato client.

Perché la convalida lato server è sicura? L'utente finale non può manipolare il codice lato server (a meno che il server non sia stato compromesso, ma si tratta di un problema separato e non facile come manipolare HTML per la persona media).

Quindi, in PHP, potrei fare un controllo come questo:

  if (! filter_var ($ _ POST ['emailAddress'], FILTER_VALIDATE_EMAIL)) {die (' Indirizzo email non valido ');}  

Sebbene questo sia un metodo di gestione degli errori non amichevole, interromperà l'esecuzione dello script se l'utente invia "andy" invece di un indirizzo email valido. L'applicazione quindi non utilizzerà mai "andy" come variabile in cui si aspettava un indirizzo di posta elettronica. Poiché l'utente finale non può manipolare il codice PHP sopra, ci sono meno possibilità che possa aggirare la convalida. Questa è la convalida lato server: non può essere (facilmente) modificata da un utente finale perché non è sotto il suo controllo modificarla.

Allora perché preoccuparsi della convalida lato client? La convalida lato client è utile per miglioramenti dell'interfaccia utente "belli" o per esempio messaggi di errore / disabilitazione dei campi modulo. Ad esempio, è probabilmente una buona funzionalità dell'interfaccia utente avere quel messaggio nel primo screenshot nel caso in cui l'utente digiti erroneamente un indirizzo e-mail. Il modulo non verrà nemmeno inviato nelle prime condizioni, riducendo così l'invio di dati non necessari al server. Ma alla fine, qualsiasi cosa eseguita sul lato client può essere modificata dall'utente finale. Quindi non è in alcun modo sicuro e non dovresti mai pensare alla "convalida lato client" quando si tratta di pratiche di sicurezza. Qualsiasi convalida lato client è principalmente solo per miglioramenti dell'interfaccia utente.

La convalida lato client è utile anche per applicazioni lato client (quando non richiede / invia a un server). Ad esempio, se avessi il modulo sopra riportato e poi visualizzato il contenuto di emailAddress in un <div> sulla pagina leggendolo con JavaScript / jquery. Se l'utente inseriva qualcosa come <script>alert ('hello!'); < / script> e non c'era convalida, avrebbe prodotto un avviso quando JavaScript tentava di scrivere il valore nel campo in <div>

. In questo caso non viene inviato nulla al server - accade tutto lato client - quindi di nuovo la convalida lato client è utile in questo tipo di scenario. Tuttavia, la stessa logica si applica in quanto un utente può ancora disabilitare la convalida. L'impatto qui è inferiore perché se eseguissero il codice sopra, accadrebbe solo sulla loro macchina locale, non ad altri utenti dell'applicazione. Ad esempio:

enter image description here

utilizzando il seguente codice (senza alcuna convalida):

  <form method = "post" action = "#" > <input type = "text" name = "emailAddress" id = "emailAddress" size = "100" >
<button type = "submit" >Submit form< / button>< / form><div id = "test" >< / div>< / form><div id = "test" >< / div> ID test:
  $ (document) .ready (function () {$ ("button"). Click (function (e) {e.preventDefault () ; $ ("# test"). html ($ ("# emailAddress"). val ());});});  
#3
+6
Bristran
2017-09-19 20:36:27 UTC
view on stackexchange narkive permalink

Come ha affermato Anders, la convalida lato client è irrilevante per la sicurezza dell'applicazione, ma molto importante dal punto di vista dell'esperienza utente.

La convalida lato client si concentra sul fornire all'utente un tempo più facile durante la compilazione dei moduli, il miglior esempio che conosco è il plug-in jQuery Masks, che può essere utilizzato per limitare le dimensioni e il modello di input fornendo un feedback visivo per l'utente. Questo può aiutarti su falle non di sicurezza, come ricevere dati dagli utenti in un modello diverso da quello previsto sul lato server, ma è facilmente ignorato da qualsiasi aggressore.

tl; dr - Non esiste una cosa del genere come convalida lato client sufficiente, semplicemente non fidarti del client, tratta semplicemente tutto ciò che viene ricevuto sul server prima di elaborarlo.

#4
+2
AnoE
2017-09-21 17:49:25 UTC
view on stackexchange narkive permalink

Nessuna delle risposte finora lo menziona realmente, quindi lasciatemi aggiungere questo:

Il motivo per cui qualsiasi cosa nel tuo HTML è completamente irrilevante per la sicurezza è che qualsiasi attaccante può , banalmente, creare richieste senza nemmeno caricare alcun HTML nel browser (digitando una richiesta nella console o utilizzando qualche plugin). In realtà, senza nemmeno avviare il browser (c / f curl , wget o qualsiasi linguaggio di programmazione).

La parte rilevante per queste cose sono richieste HTTP . Non il payload HTML. E ad eccezione del livello TLS / SSL, non c'è nulla che salvaguardi il contenuto della richiesta HTTP dalla persona che effettivamente crea la richiesta.

Quindi, qualsiasi sicurezza deve avere luogo sul server lato. Tutti i controlli lato client servono solo per una migliore esperienza utente (saltando un roundtrip).

#5
  0
Harshit Singhal
2017-09-21 21:29:37 UTC
view on stackexchange narkive permalink

Le convalide HTML verranno applicate solo a coloro che non sanno come modificare il codice html dal lato client. Queste convalide html possono essere facilmente rimosse e manipolate dal lato client.

Non c'è motivo per cui la convalida debba avvenire nel database.Ci sono molte ragioni per cui dovrebbe accadere sul lato server.
I dettagli a sostegno della tua risposta sarebbero di grande aiuto.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...