Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Checkout e sicurezza dei dati

E-commerce in PHP. In questo capitolo affronteremo il tema della sicurezza dei dati e come questi devono essere trattati dal nostro sistema di e-commerce.
E-commerce in PHP. In questo capitolo affronteremo il tema della sicurezza dei dati e come questi devono essere trattati dal nostro sistema di e-commerce.
Link copiato negli appunti

Prima di finalizzare l’acquisto tramite il pagamento, l’utente deve inserire i propri dati personali per poter concludere l’ordine. In questo capitolo affronteremo il tema della sicurezza dei dati inseriti e come questi devono essere trattati dal nostro sistema di e-commerce.

Il primo concetto da comprendere è che ogni tipo di dato inserito dall’utente è da considerarsi sospetto e potenzialmente pericoloso. Di conseguenza i dati devono essere validati prima di poter essere usati.

Validazione dei dati

Se ad esempio l’utente inserisce la propria e-mail, dobbiamo essere certi che l’input inserito corrisponda ad un indirizzo e-mail valido:

if(!filter_var(trim($_POST['billing_email']), FILTER_VALIDATE_EMAIL)) {
  // Errore
}

Questo tipo di campi non presenta problemi particolari di validazione in quanto il formato è noto e regolato da standard riconosciuti. Più complesso il discorso di quei campi che presentano un formato variabile, come ad esempio il campo in cui l’utente deve inserire il proprio nome.

In questo caso la semplice verifica della presenza di un valore non è sufficiente a proteggere la nostra applicazione da tentativi di exploiting, ad esempio tramite injection di comandi SMTP. Di conseguenza dovremo restringere il range di input tramite espressioni regolari:

if(!preg_match('/^[a-zA-Z\s]+$/', trim($_POST['billing_firstname"
']))) {
  // Errore
}

I numeri di telefono rappresentano un problema più di logica dell’usabilità che non di validazione. Di fatto un numero di telefono è una stringa composta di soli numeri, quindi avremo:

if(!preg_match('/^\d+$/', trim($_POST['phone']))) {
    // Errore
}

Il problema sorge con l’aggiunta del prefisso internazionale, ossia la stringa +codice dove il codice è il numero che rappresenta la nazione. Per risolvere questo problema, il nostro sistema non dovrebbe permettere all’utente di aggiungere il prefisso, ma dovrebbe aggiungerlo automaticamente in fase di elaborazione basandosi sulla nazione scelta dall’utente. Di conseguenza se l’utente sta acquistando dall’Italia, il prefisso aggiunto dovrebbe essere +39.

Utenti e sessioni

Il secondo concetto da comprendere riguarda la domanda circa l’identità dell’utente durante il processo di acquisto. La domanda da porsi è: l’utente approdato alla pagina di checkout è lo stesso utente che ha acquistato i prodotti aggiungendoli al carrello?

Tool come Burp permettono di manipolare i dati di una sessione PHP con facilità. Per impostazione predefinita, il cookie di sessione ha il nome PHPSESSID ed è facilmente identificabile. La funzione session_id() ci permette di modificare tale nome:

class Session {
    public static function start() {
        session_id(uniqid());
        session_start();
    }
    //...
}

A questo punto per identificare una sessione valida dobbiamo creare un token di sessione che utilizzi alcuni dati estrapolati dal client, come il browser in uso e l’indirizzo IP remoto:

class Session {
    public static function start() {
        session_id(uniqid());
        session_start();
        self::setItem('token', md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']));
    }
    //...
}

Ora dobbiamo aggiungere un metodo booleano per verificare l’integrità della sessione:

public static function isValidSession() {
   $value = md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']);
    return (self::getItem('token') === $value);
}

Quindi possiamo usare questo metodo in modo preliminare in tutti gli endpoint sensibili:

public function checkout() {
    if(!Session::isValidSession()) {
         Session::end();
         Router::redirect(SITE_URL);
    }
}

SSL/TLS

Il terzo concetto riguarda l’uso di SSL/TLS. Questa misura di protezione sulle transazioni dovrebbe essere sempre applicata in modo globale su tutto il sito, e non solo sul processo di pagamento. Non ci dovranno mai essere punti scoperti. Anche un solo form non protetto su una pagina di contatti può rivelarsi di estremo interesse per chi ha intenzione di compromettere l’integrità del sito.

Conclusione

Prima di finalizzare l’ordine è bene eseguire un check completo sul processo di acquisto per evitare che vi siano delle falle che possano compromettere l’integrità dei dati ed il pagamento.


Ti consigliamo anche