Una spiegazione con codice e schermate
Le risposte fornite sono grandiose. Ma volevo illustrarlo con codice / schermate.
La linea di fondo è che tutto il lato client può essere manipolato (disabilitato / completamente eliminato / bypassato o modificato) dall'utente finale. Quindi qualsiasi tipo di "validazione 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>
Si tratta di un indirizzo email ( type="email" ), che dice che è un campo obbligatorio (attributo required ).
Se provo a inviare qualcosa che è vuoto o meno a un indirizzo email, si verificherà un errore, ad es.
Perchéquestoèinutiledalpuntodivistadellasicurezza?Tuttociòchel'utentedevefareèmanipolarel'HTML.PossonofarlosalvandounacopiadellapaginaWeb,modificandolaeriaprendo.OppurepossonoutilizzaregliStrumentipersviluppatorinelpropriobrowserpermodificareilmarkup.Possonofarloperchésitrattadicodicelatoclient,edèsottoillorocontrollo.
Diciamochecambioilmarkupdelmoduloinquestomodo:
<formmethod="post" action="index.php">
<input type="text" name="emailAddress">
<button type="submit">Submit form</button>
</form>
Ora sto dicendo che il campo emailAddress è di tipo text (cioè non email ) e non è un campo obbligatorio (attributo required rimosso).
Quindi posso inviarlo al server. La stringa di testo "andy" non è ovviamente un indirizzo email valido. Ma dal momento che non abbiamo alcuna validazione sul lato server (ancora) sarà felicemente postata sul server e quindi se il codice PHP ha usato $_POST['emailAddress'] avrebbe "andy" come i suoi dati.
Potreiancheinviareilmodulosenzadati,nelqualcasol'applicazione,senzaalcunaconvalidasullatoserver,avrebbeunastringavuotanellavariabile$_POST['emailAddress'].
Questoerapossibilesoloperchéiocomeutentefinalepotevomanipolareilcodicelatoclient.
Perchélaconvalidalatoserverèprotetta?L'utentefinalenonpuòmanipolareilcodicelatoserver(amenocheilservernonsiastatocompromesso,masitrattadiunproblemaseparatoenondiunacosafacilecomemanipolareHTMLperlapersonamedia).
Quindi,inPHP,potreifareuncontrollocomequesto:
if(!filter_var($_POST['emailAddress'],FILTER_VALIDATE_EMAIL)){die('Invalidemailaddress');}
Sebbenesitrattidiunmetododigestionedeglierrorinonamichevole,interromperàl'esecuzionedelloscriptsel'utenteinvia"andy" invece di un indirizzo email valido. L'applicazione quindi non userà mai "andy" come variabile in attesa di un indirizzo di posta elettronica. Poiché l'utente finale non può manipolare il codice PHP sopra, ci sono meno possibilità che possano bypassare la convalida. Questa è la convalida lato server - non può essere (facilmente) modificata da un utente finale perché non è sotto il loro controllo modificarla.
Perché preoccuparsi della convalida del lato client? La convalida del lato client è utile per i miglioramenti dell'interfaccia utente "di bell'aspetto" o, ad esempio, per i messaggi di errore / disattivazione dei campi modulo. Ad esempio, è probabilmente una buona caratteristica dell'interfaccia utente avere quel messaggio sul primo screenshot nel caso in cui l'utente mis-digita un indirizzo email. Il modulo non verrà nemmeno inviato sotto la prima serie di condizioni, riducendo così i dati non necessari inviati al server. Ma alla fine, qualsiasi cosa fatta sul lato client può essere cambiata dall'utente finale. Quindi non è assolutamente sicuro e non si dovrebbe mai pensare a "validazione lato client" quando si tratta di pratiche di sicurezza. Qualsiasi validazione lato client è in gran parte solo per i miglioramenti dell'interfaccia utente.
La convalida lato client è utile anche per le applicazioni lato client (quando non richiede / invia a un server). Ad esempio se avevi il modulo di cui sopra e poi hai visualizzato il contenuto di emailAddress in un <div> nella pagina leggendolo con JavaScript / jquery. Se l'utente ha inserito qualcosa come <script>alert('hello!');</script> e non è stata convalidata, genera un avviso quando JavaScript ha tentato di scrivere il valore nel campo su <div> . Nulla viene pubblicato sul server in questo caso - tutto accade sul lato client - quindi ancora una volta la validazione lato client è utile in questo tipo di scenario. Tuttavia, si applica la stessa logica in quanto un utente può ancora disabilitare la convalida. L'impatto qui è più basso perché se eseguissero il codice sopra sarebbe accaduto solo sulla loro macchina locale, non ad altri utenti dell'applicazione. Ad esempio:
Utilizzandoilseguentecodice(senzaalcunaconvalida):
<formmethod="post" action="#">
<input type="text" name="emailAddress" id="emailAddress" size="100">
<button type="submit">Submit form</button>
</form>
<div id="test"></div>
E jquery per scrivere il contenuto del modulo in <div> con l'ID test :
$(document).ready(function() {
$("button").click(function(e) {
e.preventDefault();
$("#test").html($("#emailAddress").val());
});
});