Nella nostra pagina di login dove è presente il form per l’inserimento delle credenziali, come primissima cosa diciamo al server di iniziare una nuova sessione:

<?php session_start() ?>
/* qui ci sarà il form */

La pagina, una volta inviati i dati dal form, dovrà controllare che le credenziali siano corrette. Se lo sono possiamo salvarci dei dati grazie alla superglobale $_SESSION in questo modo:

<?php
     // salvo l'id utente
     $_SESSION['id_utente'] = $id_utente;
?>

Una volta che abbiamo salvato il nostro dato, possiamo utilizzarlo nelle pagine che seguiranno (come ad esempio una pagina della scheda di un documento riservato) in questo modo:

<?php
     session_start();
 
     if(isset($_SESSION['id_utente'])){
          // l'utente è loggato
     } else{
          die('Area ad accesso riservato');
     }
?>

Come vedete è sempre necessario inizializzare la sessione con session_start().
La primissima cosa che potrebbe venirci in mente è quella di salvarci in un’altra variabile di sessione (cookie) la password dell’utente criptata, in modo tale da effettuare il controllo della coppia id_utente – password nel nostro database.

Per concludere vediamo ora come si chiude una sessione, ad esempio per la classica azione di logout di un utente:

<?php
     session_start();
     $_SESSION = array(); // svuoto la superglobale
     session_destroy();          
?>

Attenzione
Una volta settata una variabile di sessione (cookie) è necessario eseguire un header(‘Location’) per fare in modo che la pagina stessa riconosca il cookie settato.
Ad esempio, se abbiamo il form di login contenuto nella pagina area_riservata.php e vogliamo fare in modo che, se l’utente è loggato, visualizzi un elenco di documenti, altrimenti visualizzi il form, dobbiamo fare in questo modo:

<?php
     session_start();     
 
     if($_POST['azione'] == 'invia_form'){
          // salvo l'id utente
          $_SESSION['id_utente'] = $id_utente;
          header('Location /area_riservata.php');
          exit;
     }
 
     if(isset($_SESSION['id_utente'])){
          // l'utente è loggato, visualizzo elenco doc
     } else{
          // l'utente non è loggato, visualizzo il form di login
     }
?>

Ero già pronto a prendermi le classiche espressioni regolari per controllare email, input di testo, date ecc… Ma proprio oggi leggevo un interessantissimo articolo su mattiasgeniar.be, un buon blog di uno sviluppatore, dove veniva presentata un’innovativa soluzione, introdotta con PHP5, per validare e filtrare l’input degli utenti: filter_var().

Ammetto di essere rimasto affascianato dalla semplicità con cui ora posso validare e filtrare i dati.
Ecco alcuni esempi (Attenzione: filter_var() è presente SOLO da PHP5 in poi).

Validazione di una mail:

<?php
   if(!filter_var($_POST['email'], FILTER_VALIDATE_EMAIL)) echo 'Email non valida';
?>

Strip di tutto ciò che non è una stringa (pensiamo ad esempio ad un commento nel nostro blog):

<?php
   $commento = "<h1>Ciao a tutti, il mio <a href='http://www.google.it'>blog è qui</a></h1>";
   $commento = filter_var($commento, FILTER_SANITIZE_STRING);
   // Restituisce Ciao a tutti, il mio blog è qui
?>

E questi sono solo due semplicissimi esempi che solitamente necessitano di strip_tags, espressioni regolari ecc…
Onestamente trovo questo filter_var una vera manna!

Vi lascio il link di tutti i possibili parametri (sono veramente molti) per la filter_var:
http://mattiasgeniar.be/2009/02/07/input-validation-using-filter_var-over-regular-expressions/

Se abbiamo ad esempio una stringa inviata da un utente malintezionato, che vuole inserire del codice HTML (un link ad un sito ad esempio…) possiamo fare così:

$commento = strip_tags($_POST['commento']);

E se volessimo invece abilitare all’utente la possibilità di mettere un testo in grassetto?

Possiamo fare così:

$commento = strip_tags($_POST['commento'],'<strong>');

Nel caso volessimo abilitare più di un tag possiamo utilizzare questa sintassi:

$commento = strip_tags($_POST['commento'],'<strong>,<a>');

In questo modo l’utente avrà la possibilità di mettere link e grassetti.

Attenzione: strip_tags() elimina tutti i tag HTML, ma anche i tags PHP !

Per approfondimenti: http://it2.php.net/manual/it/function.strip-tags.php

Direttamente da html.it

la SQL injection consiste nell’inserimento di query T-SQL e nella modifica di interrogazioni già esistenti nelle pagine dinamiche, così da far compiere all’applicazione un’azione del tutto imprevista.

Un altra buona definizione direttamente da wikipedia

La SQL injection è una tecnica dell’hacking mirata a colpire le applicazioni web che si appoggiano su un database di tipo SQL. Questo exploit sfrutta l’inefficienza dei controlli sui dati ricevuti in input ed inserisce codice maligno all’interno di una query SQL. Le conseguenze prodotte sono imprevedibili per il programmatore: l’Sql Injection permette al malintezionato di autenticarsi con ampi privilegi in aree protette del sito (ovviamente, anche senza essere in possesso delle credenziali d’accesso) e di visualizzare e/o alterare dati sensibili.

Soluzioni

- Non fidarsi dell’input dell’utente. Mai. Anche un utente che commette un errore , e non un malintenzionato, può provocare danni.

- Eseguire sempre l’escape dei caratteri utilizzando mysql_real_escape_string() oppure addslashes()

- Controllare la direttiva di PHP magic_quotes_gpc. Se impostata su ON non eseguire l’escape in quanto viene fatto automaticamente e procurerebbe solo un escape multiplo.

- Se stiamo ricevendo un email da un form , controlliamo che sia valida (esistono molte funzioni in giro).

- Stiamo ricevendo un dato e ci aspettiamo che sia un numero? Eseguiamo il casting (int)$_POST['input_utente']

Direttamente da phpnews.it

Se nel php.ini è abilitata la direttiva register_globals il PHP crea automaticamente, all’avvio di ogni script, delle variabili globali con i dati provenienti dall’URL, dai form, dai cookies, dalla sessione, dal server web e dal browser.

E’ chiaro che questa situazione rende la nostra vita più semplice in fase di programmazione, ma è anche vero che se non inizializziamo tutte le variabili, un malintenzionato (o anche un erorre perchè no ..) potrebbe scrivere nell’url della nostra pagina &variabile=1 e settare in questo modo una variabile che nel nostro codice potrebbe servire a molte cose… nel peggiore dei casi ad un autentificazione.

Brutta situazione vero? Da PHP 4.2 in su infatti la direttiva è stata portata di default da ON a OFF obbligandoci quindi a scrivere codice più ragionato , e quindi più sicuro.

Soluzioni

Una buona abitudine, indipendentemente dalla direttiva register_globals è inizializzare e definire SEMPRE le variabili che andremo ad usare nel nostro script.

Secondariamente bisogna impostare la direttiva register_globals ad OFF in questo modo :

Direttamente da php.ini : register_globals = false

Nel file .htaccess del nostro sito : php_flag register_globals off

Approfondimento su register_globals (inglese) : php.net http://it.php.net/register_globals