Cosa dovrebbero sapere anche i committenti di siti web — usare la 'Guida per rendere sicuro il proprio sito web' dell'IPA come checklist

· Aggiornato il: · · Sviluppo di siti web, Sicurezza informatica, Vulnerabilità, SQL Injection, Cross-Site Scripting, IPA, WordPress, B2B

Chiedere “la sicurezza del nostro sito web è a posto?” e poche aziende possono rispondere “sì” con una reale base di giudizio.

È facile presumere che vada tutto bene perché se ne occupa una web agency, o che un sito solo con profilo aziendale non sia un bersaglio — ma un solo modulo di contatto significa che gira un programma che elabora input, e se si usa un CMS come WordPress, sia la schermata di amministrazione che ogni plugin sono superfici di attacco. Inoltre la maggior parte degli attacchi non mirano a un’azienda specifica; scansionano meccanicamente siti deboli.

Quindi, contro quale standard controllare concretamente se “è a posto”? Il riferimento pubblico che da tempo svolge questo ruolo è How to Secure Your Website dell’IPA (Information-technology Promotion Agency).

Questo articolo espone cosa insegna questo riferimento, con un linguaggio comprensibile sia al committente dell’ordine sia a chi gestisce il sito.

1. La linea di fondo per prima

  • La “Guida per rendere sicuro il proprio sito web” è un riferimento costruito sulle vulnerabilità effettivamente segnalate all’IPA, riassumendo 11 categorie di debolezza dei siti web e le relative contromisure. È utile non solo per gli sviluppatori, ma come standard per l’ordine e il collaudo
  • Le contromisure si dividono in “soluzione fondamentale” (rimuove la causa) e “misura di fallback” (riduce il danno). La baseline è la soluzione fondamentale, con le misure di fallback a strato aggiuntivo
  • La “Checklist di implementazione della sicurezza” allegata si può usare direttamente come voce di verifica sia in fase di ordine che di collaudo
  • Il supplemento “Specifica di health-check del sito web” fornisce una baseline di voci diagnostiche per ispezionare periodicamente un sito in produzione
  • In pratica, per un sito aziendale, il rischio si concentra nelle parti che accettano input, come i moduli, e nelle operazioni del CMS (WordPress e simili). Decidere al momento dell’ordine una struttura operativa continuativa, così il progetto non finisce nel momento in cui il sito viene consegnato

2. Cos’è la “Guida per rendere sicuro il proprio sito web”?

La “Guida per rendere sicuro il proprio sito web” è un riferimento che l’IPA ha compilato per sviluppatori e operatori di siti web, coprendo vulnerabilità segnalate frequentemente oppure con grande impatto se sfruttate, insieme alle contromisure. La versione attuale è la 7ª edizione riveduta, pubblicata a marzo 2021, per un totale di 115 pagine. Oltre al PDF, sono pubblicate anche pagine HTML per ogni singola vulnerabilità.

È organizzata in tre capitoli.

Capitolo Contenuto
Capitolo 1: Implementazione della sicurezza nelle applicazioni web Copre minacce e contromisure (soluzioni fondamentali e misure di fallback) per 11 categorie di vulnerabilità
Capitolo 2: Sforzi per migliorare la sicurezza del sito web Copre sforzi oltre l’implementazione dell’applicazione — come le operazioni sul server — che aumentano la sicurezza del sito nel complesso
Capitolo 3: Casi di errore Copre 8 errori reali comuni, con esempi di codice sorgente e correzioni

Oltre al volume principale, sono pubblicati anche:

  • Checklist di implementazione della sicurezza (formato Excel): un elenco per confermare se le contromisure del volume principale sono state implementate
  • Volume supplementare “Come chiamare SQL in modo sicuro”: approfondimento sulle contromisure per le vulnerabilità relative ai database
  • Volume supplementare “Specifica di health-check del sito web”: specifica di 13 voci diagnostiche per valutare un sito in esercizio

Tutti questi materiali sono scaricabili gratuitamente dalla pagina dell’IPA.

3. Leggere le 11 vulnerabilità come “cosa succede se non si fa nulla”

Le 11 categorie di vulnerabilità trattate nel Capitolo 1 sono espresse in terminologia da sviluppatori, ma se le si riformula come “cosa succede sul proprio sito se lo si lascia stare”, si capisce che non sono un problema di qualcun altro nemmeno per il committente dell’ordine.

Vulnerabilità Cosa succede se non si interviene
SQL injection Il contenuto del database — storico richieste, informazioni sui soci e così via — viene rubato o sovrascritto
OS command injection Il server viene conquistato e usato come trampolino per ulteriori attacchi
Parametri di percorso non controllati (directory traversal) Vengono letti file sul server che non avrebbero dovuto essere accessibili
Gestione sessioni impropria Qualcun altro può accedere impersonando l’utente legittimo
Cross-site scripting (XSS) Nella schermata del visitatore vengono eseguiti schermate false o processi malevoli, rubando informazioni
CSRF (cross-site request forgery) Un utente loggato compie un’azione non voluta senza accorgersene
HTTP header injection Viene sfruttata per mostrare pagine false o reindirizzare a un altro sito
Mail header injection Il modulo di contatto viene abusato come dispositivo per inviare spam
Clickjacking Pulsanti invisibili vengono sovrapposti, inducendo l’utente a cliccare qualcosa di non voluto
Buffer overflow Il programma viene conquistato e fatto eseguire codice arbitrario
Mancato controllo di accesso o autorizzazione Pagine riservate ai soci o funzioni di amministrazione diventano raggiungibili da persone non autorizzate

Per esempio, la “mail header injection” si applica direttamente al modulo di contatto di un sito aziendale minimale. Un modulo mal protetto viene abusato come sorgente di spam, danneggiando anche la reputazione del dominio aziendale stesso (indipendentemente dal fatto che le sue email vengano effettivamente consegnate). Come trattato in “Perché le email del modulo di contatto non vengono consegnate”, un modulo le cui email smettono di arrivare si traduce direttamente in opportunità di business perse.

4. “Soluzioni fondamentali” e “misure di fallback” — come ragionare sulle contromisure

Ciò che rende eccellente questo riferimento è che presenta le contromisure in due categorie.

  • Soluzione fondamentale: un’implementazione che rimuove la causa principale della vulnerabilità stessa. Per l’SQL injection, per esempio, costruire le istruzioni SQL con placeholder invece di concatenazione di stringhe
  • Misura di fallback: una contromisura che riduce la probabilità di successo o l’impatto di un attacco quando una vulnerabilità rimane. Per esempio, non mostrare messaggi di errore grezzi nel browser

Questa distinzione offre al committente un metro di giudizio quando ascolta una spiegazione sulla sicurezza. Una frase come “mettiamo un WAF (meccanismo che rileva e blocca gli attacchi), quindi siete coperti” parla di una misura di fallback — non è un sostituto della soluzione fondamentale nell’applicazione stessa. Viceversa, implementare una soluzione fondamentale e poi aggiungere un WAF sopra è una configurazione solida. Saper distinguere a quale strato si riferisce chi parla permette di giudicare notevolmente meglio la solidità di una proposta.

5. Come usarla in fase di ordine e collaudo

La “Guida per rendere sicuro il proprio sito web” è scritta per sviluppatori, ma il suo valore pratico per il committente sta nel fatto che può essere usata come standard per requisiti e verifica.

  • In fase di preventivo / specifica: aggiungere una riga che dica “implementare le contromisure per le vulnerabilità elencate nella ‘Guida per rendere sicuro il proprio sito web’ dell’IPA”. Citare uno standard specifico rende il requisito molto più concreto di una frase generica come “prestare adeguata attenzione alla sicurezza”
  • In fase di collaudo: chiedere i risultati di conferma rispetto alle voci pertinenti della checklist di implementazione della sicurezza
  • In fase contrattuale: mettere per iscritto chi gestirà gli aggiornamenti del CMS, dei plugin e del server dopo il go-live, e se la risposta a una nuova vulnerabilità rientra nel contratto di manutenzione o richiede un preventivo separato

Il terzo punto conta soprattutto. La sicurezza di un sito web non finisce nel momento in cui viene consegnato — si mantiene tenendo il passo con le nuove vulnerabilità scoperte dopo il go-live. Questa domanda su “chi continua a vigilarci” ha la stessa struttura della questione di ambito di manutenzione trattata nel nostro articolo sui contratti di sviluppo e manutenzione affidati a terzi.

6. Dare a un sito in produzione un “health check”

Per un sito già in produzione, è utile il supplemento “Specifica di health-check del sito web”. È una specifica di voci diagnostiche (13 in totale) per controllare la sicurezza di un sito web in esercizio, e funge anche da guida approssimativa per l’ambito di copertura di un servizio di diagnosi delle vulnerabilità.

Per un sito aziendale di una PMI, in pratica il rischio tende a concentrarsi in due punti in particolare:

  • Le parti che accettano input: moduli di contatto, caselle di ricerca, login per i soci e così via. La maggior parte delle vulnerabilità del Capitolo 1 riguarda queste
  • Le operazioni del CMS: in un sito in cui gli aggiornamenti del core, del tema o dei plugin di un CMS come WordPress sono rimasti fermi, la classica modalità di manomissione sfrutta una debolezza nota. È estremamente comune che nessuno abbia deciso di chi sia il compito degli aggiornamenti e il sito venga semplicemente lasciato così com’è

Se si vuole ripensare all’onere degli aggiornamenti del CMS insieme all’intera struttura operativa, vale la pena dare un’occhiata anche al nostro articolo sulla migrazione da WordPress. C’è anche la scelta progettuale di ridurre complessivamente l’elaborazione dinamica favorendo una struttura di sito statico, che restringe la superficie di attacco stessa. Il nostro uso di una struttura di sito statico costruita sul design system della Digital Agency per la produzione dei siti è un’estensione dello stesso ragionamento.

Notare che operare un sito web in sicurezza è elencato come voce di controllo anche nell’autovalutazione della “Linea guida per la sicurezza informatica delle PMI” dell’IPA, edizione 4.0. Per dove collocare questo aspetto all’interno delle misure di sicurezza complessive dell’azienda, vedere il nostro articolo sulla 4ª edizione delle linee guida.

Ecco i punti chiave della “Guida per rendere sicuro il proprio sito web” dell’IPA.

  • Un riferimento standard (7ª edizione riveduta, 115 pagine) che copre 11 categorie di debolezza dei siti web e le relative contromisure, basato su vulnerabilità effettivamente segnalate all’IPA
  • Le contromisure si dividono in due strati: soluzioni fondamentali e misure di fallback. Una misura di fallback come un WAF non sostituisce una soluzione fondamentale
  • Il committente può usarla citando il riferimento nei requisiti, verificando il collaudo con la checklist e regolando per iscritto la struttura post-go-live nel contratto
  • Dare periodicamente health check al sito in produzione usando la “Specifica di health-check” come baseline
  • Per un sito aziendale, il rischio realistico tende a concentrarsi nell’elaborazione degli input come i moduli e in un CMS trascurato

La sicurezza tende a diventare una scelta tra “spendere quanto dice l’esperto” o “non fare nulla”, ma semplicemente conoscere gli standard pubblici permette di formulare richieste e verificare risultati con parole proprie.

Per chi sta considerando di realizzare o rinnovare un sito web

In fase di realizzazione o rinnovo di un sito web, Komura Software LLC propone soluzioni coerenti con il ragionamento di questo articolo — da come è implementato il modulo, a una struttura statica che non dipenda eccessivamente da un CMS, fino alla struttura operativa post-go-live. Accogliamo anche una consulenza a partire da una valutazione dello stato attuale per chi non è nemmeno sicuro di quale sia lo stato del proprio sito attuale.

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

L’articolo è direttamente collegato ai servizi seguenti.

Sviluppo di siti web

Per una nuova realizzazione o un rinnovo, le considerazioni di sicurezza trattate in questo articolo — come è implementato il modulo e come è configurato il CMS — influiscono direttamente sulla qualità del prodotto finito.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Che tipo di documento è la 'Guida per rendere sicuro il proprio sito web'?
È un riferimento sulla sicurezza pubblicato dall'IPA (Information-technology Promotion Agency) per sviluppatori e operatori di siti web. Tra le segnalazioni ricevute dall'IPA, copre le vulnerabilità più frequenti o con maggiore impatto, spiegando le minacce e le contromisure. L'attuale 7ª edizione riveduta è stata pubblicata a marzo 2021 e conta 115 pagine. Accanto al volume principale, l'IPA pubblica gratuitamente una checklist di implementazione della sicurezza e due volumi supplementari: 'Come chiamare SQL in modo sicuro' e la 'Specifica di health-check del sito web'.
Anche un sito aziendale minimale con solo profilo aziendale ha bisogno di misure di sicurezza?
Sì. Se c'è un modulo di contatto, un programma elabora l'input; se si usa un CMS come WordPress, sia la schermata di amministrazione che ogni plugin sono superfici di attacco. Gli aggressori non scelgono necessariamente il target in base alla dimensione aziendale; scansionano meccanicamente siti deboli e li abusano come trampolini di lancio per manomissioni, distribuzione di malware o invio di spam. Ciò che rende pericoloso un sito web è che, mentre se ne è vittima, si possono danneggiare contemporaneamente anche partner commerciali e visitatori.
Qual è la differenza tra soluzione fondamentale e misura di fallback?
La 'Guida per rendere sicuro il proprio sito web' presenta le contromisure in due categorie. Una soluzione fondamentale è un approccio implementativo che rimuove la causa principale della vulnerabilità (per esempio, usare placeholder invece della concatenazione di stringhe per costruire istruzioni SQL). Una misura di fallback riduce la probabilità di successo o l'impatto di un attacco quando la vulnerabilità rimane (per esempio, non mostrare messaggi di errore grezzi). Poiché le misure di fallback da sole lasciano la causa principale al suo posto, l'ordine corretto è considerare la soluzione fondamentale come baseline e aggiungere le misure di fallback sopra.
Cosa dovrei controllare sulla sicurezza quando ordino un sito a una web agency?
Al minimo, consigliamo di confermare tre cose in fase di preventivo: (1) se sono implementate le contromisure elencate nella 'Guida per rendere sicuro il proprio sito web' dell'IPA, (2) se i risultati possono essere mostrati usando la checklist di implementazione della sicurezza allegata o simile, e (3) chi gestirà gli aggiornamenti del CMS e dei plugin dopo il go-live (cioè se rientra nel contratto di operatività/manutenzione). I requisiti di sicurezza costano molto se aggiunti in corso d'opera, quindi è importante confermarli per iscritto prima della firma del contratto.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Torna al blog