I lettori come te aiutano a sostenere MUO. Quando effettui un acquisto utilizzando i link sul nostro sito, potremmo guadagnare una commissione di affiliazione.

Quando desideri visitare un sito Web, il browser Internet che utilizzi riceve alcuni dati da quel sito. Di conseguenza, si verifica un dialogo tra il tuo dispositivo e il sito web. Questo accade con il protocollo chiamato HTTP. È possibile adottare alcune misure di sicurezza aggiuntive intervenendo in questo dialogo.

Se gestisci un sito web o miri alla carriera di sviluppatore web, le intestazioni di sicurezza HTTP sono preziose per te, perché svolgono un ruolo attivo nella sicurezza sia dell'utente che del sito web.

Che cos'è HTTP Strict-Transport-Security (HSTS)?

HTTP Strict Transport Security (HSTS) obbliga gli utenti a utilizzare HTTPS per ogni richiesta che effettuano nel proprio browser. Questo è un modo solido per combattere gli attacchi informatici come i downgrade e per garantire la sicurezza di tutto il traffico.

L'attivazione di HSTS è piuttosto semplice. Considera il dialogo tra client e server. Quando provi ad accedere a un sito tramite il tuo browser, sei il cliente. Il sito che vuoi aprire dipende dal server. Il tuo obiettivo è dire al server: "Voglio aprire questo sito". Questa è un'operazione di richiesta. Il server, invece, ti indirizza al sito se soddisfi le condizioni desiderate.

instagram viewer

Tienilo a mente per quanto riguarda questo flag di intestazione HTTP di esempio:

Strict-Transport-Security: età massima=16070200;

Quando aggiungi questo flag alle informazioni di intestazione della risposta HTTP, tutte le richieste generate dall'utente diventeranno HTTPS. Qualunque cosa l'utente scriva qui, il browser valuterà automaticamente il protocollo come HTTPS e stabilirà una connessione sicura.

Come usare HSTS

Invece di aggiungere tutte queste informazioni di intestazione HTTP nel livello di codice, puoi farlo su Apache, IIS, Nginx, Tomcat e altre applicazioni di server web.

Per abilitare HSTS in Apache:

LoadModule headers_module modules/mod_headers.so
<Host virtuale *:443>
Testata sempre impostatoRigoroso-Trasporto-Sicurezza "età-max=2592000; includeSottodomini"
</VirtualHost>

Per abilitare HSTS in Nginx:

add_header Strict-Transport-Security max-age=2592000; includeSottodomini

Per abilitare HSTS con IIS web.config:

<sistema.webServer>
<httpProtocol>
<customHeaders>
<aggiungi nome="Rigorosa sicurezza dei trasporti" valore="max-età=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>

Per gli utenti di Cloudflare

Cloudflare offre un servizio HTTPS gratuito per tutti con il suo servizio Keyless SSL; prima di richiedere il precaricamento HSTS, dovresti sapere che il tuo certificato non ti appartiene. Molti siti utilizzano certificati SSL perché sono un modo semplice per proteggere i dati.

Tuttavia, Cloudflare ora supporta la funzione HSTS. Puoi attivare tutte le funzionalità HSTS, incluso il precaricamento, tramite l'interfaccia web di Cloudflare senza problemi con le configurazioni sul server web.

Cos'è X-Frame-Options?

X-Frame-Options è un'intestazione di sicurezza supportata da tutti i browser moderni. X-Frame-Options mira a proteggere dal furto di clic come il clickjacking. Come suggerisce il nome, si tratta del funzionamento di un frame in linea vulnerabile, noto anche come iframe. Si tratta di elementi su un sito che incorporano un'altra pagina HTML all'interno del sito "padre", quindi puoi utilizzare contenuti da altre fonti sul tuo sito. Ma gli aggressori utilizzano gli iframe sotto il proprio controllo per indurre gli utenti a eseguire azioni che non desiderano.

Per questo motivo, è necessario impedire agli aggressori di trovare iframe sul sito.

Dove e come utilizzare le opzioni X-Frame?

Cosa fa X-Frame-Options, alcuni sviluppatori provano a farlo con linguaggi come JavaScript. Questo non è del tutto sbagliato. Tuttavia, c'è ancora un rischio perché i codici scritti in molti aspetti non sono sufficienti. Quindi sarebbe saggio lasciare questo compito al browser Internet che stai utilizzando.

Tuttavia, come sviluppatore, ci sono tre parametri da conoscere su X-Frame-Options:

  • Negare: impedisce completamente che la pagina venga richiamata in qualsiasi iframe.
  • STESSA ORIGINE: impedisce a qualsiasi dominio diverso dal tuo di effettuare chiamate all'interno dell'iframe.
  • PERMETTI-DA uri: accetta chiamate iframe dell'URI fornito come parametro. Blocca gli altri.

Ecco, il STESSA ORIGINE caratteristica spicca di più. Perché mentre puoi chiamare le applicazioni nei tuoi diversi sottodomini con iframe all'interno dell'altro, puoi impedire che vengano chiamate sul dominio sotto il controllo dell'attaccante.

Ecco alcuni esempi di come puoi utilizzare SAMEORIGIN e X-Frame-Options con NGINX, Apache e IIS:

Utilizzo di X-Frame-Options SAMEORIGIN per Nginx:

add_header X-Frame-Options SAMEORIGIN;

Utilizzo di X-Frame-Options SAMEORIGIN per Apache:

L'intestazione aggiunge sempre X-Frame-Options SAMEORIGIN

Utilizzo di X-Frame-Options SAMEORIGIN per IIS:

<httpProtocol>
<customHeaders>
<aggiungi nome="Opzioni X-Frame" valore="STESSA ORIGINE" />
</customHeaders>
</httpProtocol>

La semplice aggiunta della sola intestazione SAMEORIGIN fornirà maggiore sicurezza ai tuoi visitatori.

Cos'è la protezione X-XSS?

L'uso delle informazioni di intestazione X-XSS-Protection può proteggere gli utenti dagli attacchi XSS. In primo luogo, è necessario eliminare Vulnerabilità XSS lato applicazione. Dopo aver fornito la sicurezza basata su codice, sono necessarie ulteriori misure, ad esempio le intestazioni X-XSS-Protection, contro le vulnerabilità XSS nei browser.

Come utilizzare la protezione X-XSS

I browser moderni possono rilevare potenziali payload XSS filtrando i contenuti generati dall'applicazione. È possibile attivare questa funzione con le informazioni di intestazione X-XSS-Protection.

Per abilitare l'intestazione X-XSS-Protection in Nginx:

add_header X-Frame-X-XSS-Protezione 1;

Per abilitare l'intestazione X-XSS-Protection in Apache:

L'intestazione aggiunge sempre X-XSS-Protezione 1

Per abilitare l'intestazione X-XSS-Protection in IIS:

<httpProtocol>
<customHeaders>
<aggiungi nome="Protezione X-XSS" valore="1" />
</customHeaders>
</httpProtocol>

Per impedire l'esecuzione predefinita del blocco di codice con attacco XSS, puoi utilizzare qualcosa del genere:

Protezione X-XSS: 1; modalità=blocco

Questa modifica minore deve essere apportata se esiste una situazione potenzialmente pericolosa e si desidera impedire il rendering di tutto il contenuto.

Che cos'è X-Content-Type-Options?

I browser eseguono un'analisi chiamata MIME Type Sniffing sul contenuto presentato loro dall'applicazione web. Ad esempio, se c'è una richiesta di accesso a un file PDF o PNG, i browser che eseguono l'analisi sulla risposta HTTP deducono il tipo di file.

Considera un file con un'estensione jpeg ma che in realtà ha un contenuto di testo/HTML. Dopo aver utilizzato le estensioni e superato le protezioni nel modulo di caricamento, il file viene caricato correttamente. Il file caricato viene chiamato tramite l'URL e lo sniffing del tipo MIME restituisce testo/HTML come risultato. Rende il contenuto come HTML. Questo è quando si verifica la vulnerabilità XSS.

Quindi è necessario impedire ai browser di decidere sul contenuto mediante lo sniffing del tipo MIME. Per fare questo, puoi usare nosniff.

Intestazione X-Content-Type-Options per Nginx:

add_header X-Content-Type-Opzioni nosniff;

Intestazione X-Content-Type-Options per Apache:

Intestazione sempre X-Content-Type-Options nosniff

Intestazione X-Content-Type-Options per IIS:

<httpProtocol>
<customHeaders>
<aggiungi nome="X-Content-Type-Opzioni" valore="annusare" />
</customHeaders>
</httpProtocol>

Che cos'è il flag dei cookie HttpOnly?

Le applicazioni Web tengono traccia delle sessioni degli utenti tramite l'ID di sessione. I browser lo memorizzeranno e lo aggiungeranno automaticamente a ogni richiesta HTTP all'interno dell'ambito del cookie.

È possibile utilizzare i cookie per scopi diverso dal trasferimento della chiave di sessione, tuttavia. Gli hacker potrebbero scoprire i dati degli utenti utilizzando la suddetta vulnerabilità XSS o tramite un attacco Cross-Site Request Forgery (CSRF). Quindi quali sono i cookie più importanti in termini di sicurezza?

Puoi considerare come esempio le informazioni contenute nell'ultima immagine che hai cliccato nella galleria immagini. In questo modo il traffico HTTP è minore e una parte del carico può essere risolta dal browser internet dell'utente con scripting lato client.

Ecco dove HttpOnly entra. Di seguito è riportato un esempio di come dovrebbe essere l'assegnazione dei cookie:

Impostato-biscotto: utente=t=cdabe8a1c2153d726; percorso=/; HttpOnly

Notare il valore HttpOnly inviato nel file Set-Cookie operazione. Il browser lo vedrà e non elaborerà i valori con il flag HttpOnly quando si accede al cookie tramite il documento.cookie variabile. Un altro flag utilizzato nel processo Set-Cookie è il flag Secure. Ciò indica che il valore del cookie verrà aggiunto all'intestazione solo per le richieste HTTPS. I siti di e-commerce di solito lo usano perché vogliono ridurre il traffico di rete e aumentare le prestazioni.

Utilizzando questo metodo, puoi nascondere i dati critici degli utenti come nomi utente, password e informazioni sulla carta di credito. Ma c'è un problema. Agli utenti che completano il processo di accesso viene assegnato un valore cookie senza il flag Secure. L'utente può avere la chiave di sessione quando effettua una richiesta HTTP a collegamenti non HTTPS. Aggiungere il flag di sicurezza è facile:

Impostato-biscotto: utente=t=cdabe8a1c2153d726; percorso=/; Sicuro

Quando non dovresti usare HttpOnly? Se ti affidi a Javascript, dovresti stare attento perché questo può invece rendere il tuo sito meno sicuro.

Piccoli passi funzionano per la sicurezza del Web più ampio

Non hai bisogno di conoscenze avanzate di software e server per aumentare la sicurezza delle applicazioni web. Modificando solo poche righe, puoi prevenire alcuni gravi attacchi. Naturalmente, questo non è abbastanza. Tuttavia, è un piccolo ma efficace passo per la sicurezza del sito web. La conoscenza è la migliore prevenzione, quindi è anche utile conoscere le sottili sfumature di come HTTPS protegge i dati durante il trasferimento.