Questa traduzione fornita da StrongLoop / IBM.

È possibile che questo documento non sia aggiornato poiché la documentazione è in inglese. Per gli ultimi aggiornamenti, fare riferimento alla documentazione in inglese.

✖

Best Practice sulla produzione: Sicurezza

Panoramica

Il termine “produzione” si riferisce alla fase nel ciclo di vita del software quando un’applicazione o API è solitamente disponibile per gli utenti finali o i consumatori. Al contrario, nella fase “sviluppo”, si sta ancora scrivendo e verificando il codice e l’applicazione non è aperta ad accessi esterni. Gli ambienti di sistema corrispondenti sono noti rispettivamente come ambienti di produzione e di sviluppo.

Gli ambienti di sviluppo e produzione sono solitamente configurati diversamente e hanno requisiti molto differenti. Ciò che potrebbe andare bene nello sviluppo potrebbe non essere accettato nella produzione. Ad esempio, in un ambiente di sviluppo è possibile che si richieda una registrazione degli errori ridondante per il processo di debug, mentre la stessa richiesta in un ambiente di produzione potrebbe mettere a rischio la sicurezza. Inoltre, in un ambiente di sviluppo non è necessario preoccuparsi della scalabilità, dell’affidabilità e delle prestazioni, mentre nella produzione è fondamentale tenerne conto.

In questo articolo vengono descritte alcune best practice sulla sicurezza per le applicazioni Express distribuite per la produzione.

Non utilizzare versioni obsolete o vulnerabili di Express

Express 2.x e 3.x non sono più supportati. I problemi relativi alla sicurezza e alle prestazioni in queste versioni non verranno risolti. Non utilizzare queste versioni! Se non è stato effettuato l’aggiornamento alla versione 4, consultare la guida alla migrazione.

Inoltre, assicurarsi che non si stia utilizzando nessuna delle versioni vulnerabili di Express elencate nella pagina Aggiornamenti sulla sicurezza. Nel caso si stia utilizzando una di queste versioni, effettuare l’aggiornamento a una versione aggiornata, preferibilmente l’ultima.

Utilizzare TLS

Se l’applicazione utilizza o trasmette dati riservati, utilizzare Transport Layer Security (TLS) per proteggere la connessione e i dati. Questa tecnologia codifica i dati prima che vengano inviati dal client al server, proteggendo i dati da alcuni attacchi comuni (e facili) da parte di hacker. Anche se le richieste Ajax e POST possono non essere visibili e “nascoste” nei browser, il relativo traffico di rete è vulnerabile agli attacchi packet sniffing e man-in-the-middle.

Sicuramente si conosce la crittografia SSL (Secure Socket Layer). TLS non è altro che un miglioramento di SSL. In altre parole, se prima si utilizzava SSL, considerare l’opportunità di passare a TLS. Consigliamo di utilizzare Nginx per gestire la TLS. Per informazioni su come configurare correttamente TLS su Nginx (e altri server), consultare Recommended Server Configurations (Mozilla Wiki).

Inoltre, uno strumento molto semplice da utilizzare per ottenere un certificato gratuito TLS è Let’s Encrypt, un CA (certificate authority) gratuito, automatizzato e open fornito da Internet Security Research Group (ISRG).

Utilizzare Helmet

Helmet è utile per proteggere l’applicazione da alcune vulnerabilità web note configurando le intestazioni HTTP in modo appropriato.

Attualmente, Helmet non è altro che una raccolta di nove funzioni middleware più piccole che impostano le intestazioni HTTP relative alla sicurezza:

Installare Helmet come qualsiasi altro modulo:

$ npm install --save helmet

Successivamente, per utilizzarlo nel codice:


...
var helmet = require('helmet');
app.use(helmet());
...

Disattivare almeno l’intestazione X-Powered-By

Se non si desidera Helmet, disattivare almeno l’intestazione X-Powered-By. Gli hacker possono utilizzare questa intestazione (abilitata per impostazione predefinita) per rilevare le applicazioni su cui è in esecuzione Express e successivamente avviare attacchi indirizzati in modo specifico.

Quindi, la miglior cosa da fare è disattivare l’intestazione con il metodo app.disable():


app.disable('x-powered-by');

Se si utilizza helmet.js, questa operazione sarà effettuata per conto dell’utente.

Per fare in modo che i cookie non espongano a rischi l’applicazione, non utilizzare il nome cookie della sessione predefinita e impostare le opzioni di sicurezza dei cookie in modo appropriato.

Esistono due moduli di sessione cookie middleware principali:

La differenza principale tra questi due moduli è nel modo in cui salvano i dati di sessione dei cookie. Il middleware express-session memorizza i dati di sessione sul server; salva l’ID sessione nello stesso cookie e non nei dati di sessione. Per impostazione predefinita, utilizza il processo di memorizzazione in-memory e non è progettato per un ambiente di produzione. Nella produzione, sarà necessario configurare un processo di memorizzazione della sessione scalabile; consultare l’elenco di compatible session stores.

Al contrario, il middleware cookie-session implementa la memorizzazione di backup dei cookie: suddivide in serie l’intera sessione per il cookie, piuttosto che una chiave di sessione. Utilizzarlo solo quando i dati di sessione sono relativamente piccoli e facilmente codificati come valori primitivi (piuttosto che oggetti). Poiché si presuppone che i browser supportino almeno 4096 byte per cookie, per non superare il limite, non superare la dimensione di 4093 byte per dominio. Inoltre, fare attenzione perché i dati dei cookie saranno visibili al cliente, quindi, se per qualche motivo devono rimanere sicuri o non visibili, la scelta di utilizzare express-session potrebbe essere quella giusta.

L’utilizzo del nome del cookie della sessione predefinito potrebbe esporre l’applicazione ad attacchi da parte di hacker. Il problema di sicurezza messo in discussione è simile a quello di X-Powered-By: un potenziale hacker potrebbe utilizzarlo per individuare il server e indirizzare gli attacchi di conseguenza.

Per evitare questo problema, utilizzare i nomi dei cookie predefiniti; ad esempio, utilizzando il middleware express-session:


var session = require('express-session');
app.set('trust proxy', 1) // trust first proxy
app.use( session({
   secret : 's3Cur3',
   name : 'sessionId',
  })
);

Impostare le seguenti opzioni per i cookie per aumentare la sicurezza:

Esempio di utilizzo del middleware cookie-session:


var session = require('cookie-session');
var express = require('express');
var app = express();

var expiryDate = new Date( Date.now() + 60 * 60 * 1000 ); // 1 hour
app.use(session({
  name: 'session',
  keys: ['key1', 'key2'],
  cookie: { secure: true,
            httpOnly: true,
            domain: 'example.com',
            path: 'foo/bar',
            expires: expiryDate
          }
  })
);

Ulteriori informazioni

Ecco alcuni consigli sull’eccellente Node.js Security Checklist. Fare riferimento a quel post del blog per tutti i dettagli su questi consigli:

Evitare altre vulnerabilità note

Prestare attenzione alle avvertenze Node Security Project che potrebbero influenzare Express o altri moduli utilizzati dall’applicazione. Solitamente, il Node Security Project è una risorsa eccellente per questioni di apprendimento e per gli strumenti sulla sicurezza di Node.

Infine, le applicazioni Express, come anche altre applicazioni web, possono essere vulnerabili ad una vasta gamma di attacchi basati su web. Cercare di comprendere al meglio le vulnerabilità web note e prendere precauzioni per evitarle.