Ho diverse applicazioni Web in esecuzione sul mio server (Debian 8 con Apache). Uno dei miei clienti vuole migliorare la sicurezza della sua app, dopo aver effettuato alcuni controlli di sicurezza effettuati da una società di terze parti, mi ha mostrato le vulnerabilità che voleva correggere, una di queste è l'intestazione X-Frame-Options mancante.
Mentre l'intestazione è presente nell'applicazione HTTPS, manca in quella HTTP.
A causa dei diversi requisiti delle applicazioni Web esposte dalla stessa istanza di Apache, non posso definire un'intestazione X-Frame-Options univoca direttamente nel file httpd.conf .
Ho configurato un reindirizzamento interno http -> https , quindi aggiungo il www. , ad es. webappaddress.com -> www.webappaddress.com .
Il problema risiede nel chiedere esplicitamente la versione HTTP, ma non ottenere l'intestazione prima del reindirizzamento. Quello che succede è: get http version -> redirect on https -> redirect to www.* if missing .
La mia configurazione su virtualhost (sia per 80 che 443 ):
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}$1 [R,L]
La mia configurazione su .htaccess :
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
<If "%{HTTP_HOST} != 'www.webappaddress.com'">
Header set Content-Security-Policy "default-src 'self'; style-src 'unsafe-inline' 'self' ;"
Header always set Referrer-Policy "origin-when-cross-origin"
</If>
Quindi la mia teoria è il clickjacking potrebbe essere ancora possibile prima che si verifichi il reindirizzamento (dimmi se ho torto), ma se guardi Facebook o Google sembrano seguire lo stesso approccio: nessun header di sicurezza prima del http- & gt ; https redirect.
