6. Considerazioni sulla sicurezza

6. Considerazioni sulla sicurezza

Le applicazioni che utilizzano HTTP devono considerare attentamente la sicurezza. Questa sezione evidenzia alcune considerazioni chiave sulla sicurezza; vedere anche [HTTP] Sezione 17.

Le applicazioni DOVREBBERO utilizzare TLS [RFC8446] per tutte le comunicazioni. In particolare, le applicazioni DEVONO utilizzare TLS quando trasmettono informazioni sensibili come credenziali di autenticazione o dati personali. Vedere [RFC7258] per ulteriori informazioni sulla necessità di crittografia ubiqua.

Le applicazioni DOVREBBERO utilizzare lo schema URI "https" anziché "http" per garantire che venga utilizzato TLS. Quando viene utilizzato TLS, le applicazioni DOVREBBERO seguire le migliori pratiche attuali, tra cui:

• Utilizzo di TLS 1.3 [RFC8446] o versioni successive.

• Validazione dei certificati del server.

• Utilizzo di suite di cifratura appropriate.

• Considerazione dell'uso di HTTP Strict Transport Security (HSTS) [RFC6797] per garantire che i browser utilizzino sempre HTTPS.

Le applicazioni devono essere consapevoli di vari attacchi basati sul Web e di come mitigarli:

• Cross-Site Scripting (XSS): Se un'applicazione restituisce contenuto che può essere interpretato come HTML o JavaScript da un browser, deve correttamente eseguire l'escape o sanificare quel contenuto per prevenire attacchi XSS. L'uso appropriato di Content-Type e l'impostazione di intestazioni Content-Security-Policy [CSP] possono aiutare.

• Cross-Site Request Forgery (CSRF): Le applicazioni che mantengono lo stato (ad esempio, utilizzando cookie) devono proteggersi dagli attacchi CSRF, in cui un sito malevolo induce il browser di un utente a effettuare richieste all'applicazione. Le mitigazioni comuni includono l'uso di token CSRF e il controllo dei campi di intestazione Origin o Referer.

• Attacchi di injection: Le applicazioni che incorporano input dell'utente in query, comandi o altri dati strutturati devono validare e sanificare correttamente quell'input per prevenire attacchi di injection (ad esempio, SQL injection).

• Divulgazione di informazioni: Le applicazioni devono fare attenzione a quali informazioni includono nei messaggi di errore, nei campi di intestazione e in altre risposte. I messaggi di errore dettagliati possono aiutare gli aggressori a comprendere gli interni dell'applicazione.

Le applicazioni DOVREBBERO considerare le implicazioni di sicurezza della memorizzazione nella cache. In particolare:

• Le informazioni sensibili NON DOVREBBERO essere memorizzate nella cache, o se devono essere memorizzate nella cache, dovrebbero essere memorizzate solo privatamente (utilizzando Cache-Control: private).

• Le credenziali di autenticazione NON DOVREBBERO essere incluse negli URL, poiché potrebbero essere registrate o memorizzate nella cache.

Le applicazioni che utilizzano l'autenticazione devono considerare:

• Come vengono trasmesse le credenziali di autenticazione (dovrebbero essere protette da TLS).

• Quanto durano le sessioni di autenticazione e come possono essere revocate.

• Come proteggersi da attacchi brute-force sull'autenticazione.

• Se l'autenticazione a più fattori è appropriata.

Le applicazioni DOVREBBERO essere consapevoli che i client e i server potrebbero non essere sotto il controllo dei progettisti dell'applicazione. In particolare:

• Gli intermediari (proxy, CDN, ecc.) potrebbero memorizzare nella cache, registrare o modificare richieste e risposte.

• I client potrebbero essere malevoli o compromessi.

• I server potrebbero essere compromessi.

Le applicazioni DOVREBBERO quindi:

• Utilizzare crittografia e autenticazione end-to-end ove appropriato.

• Non fare affidamento esclusivamente sulla sicurezza del livello di trasporto per operazioni sensibili.

• Validare tutto l'input dai client.

• Essere consapevoli del principio del minimo privilegio ed evitare di dare ai client o ai server più accesso del necessario.

Le applicazioni che consentono agli utenti di caricare contenuti o eseguire codice devono essere estremamente attente riguardo al sandboxing e all'isolamento. Anche funzionalità apparentemente benigne possono essere abusate:

• I caricamenti di file potrebbero contenere contenuti malevoli che potrebbero sfruttare vulnerabilità nei parser o nei visualizzatori.

• Gli URL controllati dall'utente potrebbero essere utilizzati per attacchi Server-Side Request Forgery (SSRF).

• Le funzionalità che eseguono codice fornito dall'utente (ad esempio, JavaScript in un contesto browser) richiedono un forte isolamento.

Le applicazioni accessibili dai browser Web devono essere particolarmente attente perché i browser hanno un modello di sicurezza complesso con molte potenziali insidie. Le applicazioni DOVREBBERO:

• Utilizzare intestazioni Content-Security-Policy appropriate [CSP] per limitare ciò che i browser possono fare.

• Utilizzare politiche CORS appropriate [FETCH] per controllare l'accesso cross-origin.

• Impostare cookie con flag appropriati (Secure, HttpOnly, SameSite).

• Considerare l'uso di X-Frame-Options o della direttiva frame-ancestors di CSP per prevenire il clickjacking.

• Essere consapevoli di comportamenti specifici del browser come prefetching, DNS prefetching e preconnecting.

• Considerare l'uso di Subresource Integrity (SRI) per garantire che le risorse ospitate esternamente non siano state manomesse.

Le applicazioni DOVREBBERO essere consapevoli che le funzionalità HTTP possono talvolta essere abusate:

• I reindirizzamenti possono essere utilizzati per phishing o per aggirare i controlli di sicurezza.

• Richieste o risposte di grandi dimensioni possono essere utilizzate per attacchi denial-of-service.

• L'analisi complessa dei campi di intestazione o del contenuto può portare a vulnerabilità.

Infine, le applicazioni DOVREBBERO avere una chiara politica di sicurezza e dovrebbero essere progettate con la sicurezza in mente fin dall'inizio. La sicurezza non dovrebbe essere un ripensamento.