I controlli client-side su quanto digitato o fatto dall'utente servono unicamente all'utente stesso come "feedback" delle sue azioni; per ciò che concerne la sicurezza, i controlli lato server divengono strettamente necessari, tanto più necessari quanto più l'applicazione Web sia diffusa e tratti dati sensibili.
Poniamo l'esempio in cui si voglia evitare di inserire dati duplicati, è già conservati nel database, nel box Nome tipo di un form Web:
Figura 2: un modulo di salvataggio dati

Il codice necessario è, banalmente, il seguente:
function verifica_nome(campo)
{
filesEsistenti=new Array();
filesEsistenti=['FAX','DOCUMENTO GENERICO','COMUNICAZIONI INTERNE','COMMESSA'];
// array eventualmente costruito dinamicamente da PHP.
if (filesEsistenti.in_array(campo.value.toUpperCase()))
{
alert ("Il nome utilizzato è già esistente. ");
campo.value = "";
campo.focus();
return true;
}
}
Ossia una funzione JavaScript richiamata tramite lo handler OnBlur nel relativo input box HTML:
<input type="text" name="nome_tipo" OnBlur="verifica_nome(this)">
Essendo, a sua volta, il form dichiarato come segue:
<form action="ins_tipo.php" method="post" enctype="multipart/form-data" name="form1" id="form1">
Un controllo lato client di questo tipo è però "bypassabile" in ben tre maniere semplicissime.
È sufficiente salvare il file HTML ed omettere (con qualsiasi editor testuale) i controlli JavaScript detti, avendo cura di modificare il parametro action del form in modo che punti all'URL del Web server in questione (qui: http://www.my_srv.com):
<form action="http://www.my_srv.com/ins_tipo.php" method="post" enctype="multipart/form-data" name="form1" id="form1">
<input type="text" name="nome_tipo" OnBlur="">
Lo stesso risultato può essere ottenuto inviando tale pagina, comprensiva di variabili POST, in HTTP via socket da un qualsivoglia programma (anche script PHP) oppure direttamente via Telnet (porta remota 80).
Come dite? Molto rumore per nulla? È sufficiente disabilitare il JavaScript dalle opzioni del browser? Già…
Senza un controllo lato server, abbiamo, in questo caso, con elevatissima probabilità, procurato un danno al programma remoto: l'importanza del data filtering ricorre ancora una volta - e siamo solo all'inizio della guida...
Alcune volte i programmatori alle prime armi escludono possibili caratteri pericolosi esattamente in questo modo, solamente via JavaScript: abbiamo visto che è una pratica da evitare.
È da notare che un controllo di sessione non può nulla al fine di evitare simili attacchi, in quanto, una volta autenticati, possiamo spedire qualsiasi cosa desideriamo dal nostro client al server remoto. E potremo sempre dire di "non averlo fatto apposta"… in questo caso la parola spetterebbe sì ai legali, ma anche il programmatore sarebbe costretto a prendersi le sue (corpose) responsabilità.
Sessioni PHP: cosa sono, come si usanoDalla configurazione di PHP, alla gestione delle sessioni in un... |
Continuous Integration: automatizziamo i client con PhingContinuous Integration: automatizziamo i client con Phing. Esempi... |
Archiviazione delle applicazioni PHP con PharCome incorporare intere applicazioni PHP all'interno di un singolo... |
I traits in PHP 5.4Cosa sono, a cosa servono e come si unsano i traits, la novità per... |
PHP 5.4: il web server integratoImpara ad usare il web server integrato nella versione 5.4 di PHP:... |
Guida Yii FrameworkCome creare applicazioni Web in modo semplice e veloce con il... |
Guida Applicazioni Facebook con PHPCome realizzare un'applicazione per Facebook. Dalle basi della... |
Guida PHP con Windows e IISInstallare ambienti per lo sviluppo e la produzione di applicazioni... |
Ogni lunedì, direttamente nella tua e-mail: script, articoli, guide e tutorial su PHP, MySQL e Apache.
Iscriviti alla newsletter
|
|
Corso PHP per Webmaster11 Giugno 2012 a Milano |
|
|
Corso Google AdWords Base25 Giugno 2012 a Milano |
|
|
Corso Google AdWords Base05 Giugno 2012 a Roma |