From c2d163f142f3578043c90315f48f709d42df9956 Mon Sep 17 00:00:00 2001 From: Christoph Date: Mon, 30 Oct 2017 03:57:36 +0100 Subject: [PATCH] Add security http headers to vhost configuration. Change IMAP AUTH type (['imap_auth_type']) to value 'LOGIN'. --- install_roundcube.sh | 309 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 307 insertions(+), 2 deletions(-) diff --git a/install_roundcube.sh b/install_roundcube.sh index 990b61f..f36fc22 100755 --- a/install_roundcube.sh +++ b/install_roundcube.sh @@ -1110,6 +1110,80 @@ cat < ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file RewriteCond %{HTTPS} !=on RewriteRule (.*) https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L] + # ========== + # - HTTP security Headers + # ========== + + # - X-Frame-Options + # - + # - The X-Frame-Options header (RFC), or XFO header, protects your visitors + # - against clickjacking attacks. An attacker can load up an iframe on their + # - site and set your site as the source, it's quite easy: + # - + # - + # - + # - Using some crafty CSS they can hide your site in the background and create some + # - genuine looking overlays. When your visitors click on what they think is a harmless + # - link, they're actually clicking on links on your website in the background. That + # - might not seem so bad until we realise that the browser will execute those requests + # - in the context of the user, which could include them being logged in and authenticated + # - to your site! + # - + # - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front : + # - of you': + # - + # - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html + # - + # - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows + # - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify + # -sites that are permitted to frame your own site. + # - + Header always set X-Frame-Options "SAMEORIGIN" + + # - X-Xss-Protection + # - + # - This header is used to configure the built in reflective XSS protection found + # - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header + # - are 0, which disables the protection, 1 which enables the protection + # - and 1; mode=block which tells the browser to block the response if it + # - detects an attack rather than sanitising the script. + # - + Header always set X-Xss-Protection "1; mode=block" + + # - X-Content-Type-Options + # - + # - Nice and easy to configure, this header only has one valid value, nosniff. + # - It prevents Google Chrome and Internet Explorer from trying to mime-sniff + # - the content-type of a response away from the one being declared by the server. + # - It reduces exposure to drive-by downloads and the risks of user uploaded content + # - that, with clever naming, could be treated as a different content-type, like + # - an executable. + # - + Header always set X-Content-Type-Options "nosniff" + + # - Content Security Policy + # - + # - The CSP header allows you to define a whitelist of approved sources of content + # - for your site. By restricting the assets that a browser can load for your site, + # - like js and css, CSP can act as an effective countermeasure to XSS attacks. I + # - have covered CSP in a lot more detail in my blog Content Security Policy - An + # - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/). + # - + # - Here is a basic policy to enforce TLS on all assets and prevent + # - mixed content warnings. + # - + # + Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'" + + # - Referrer-Policy + # - + # - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header + # - field that identifies the address of the webpage (i.e. the URI or IRI) that + # - linked to the resource being requested. By checking the referrer, the new + # - webpage can see where the request originated. + # - + Header set Referrer-Policy "strict-origin-when-cross-origin + CustomLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-access.log combined ErrorLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-error.log @@ -1178,7 +1252,79 @@ EOF fi cat <> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file - SSLEngine on + # ========== + # - HTTP security Headers + # ========== + + # - X-Frame-Options + # - + # - The X-Frame-Options header (RFC), or XFO header, protects your visitors + # - against clickjacking attacks. An attacker can load up an iframe on their + # - site and set your site as the source, it's quite easy: + # - + # - + # - + # - Using some crafty CSS they can hide your site in the background and create some + # - genuine looking overlays. When your visitors click on what they think is a harmless + # - link, they're actually clicking on links on your website in the background. That + # - might not seem so bad until we realise that the browser will execute those requests + # - in the context of the user, which could include them being logged in and authenticated + # - to your site! + # - + # - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front : + # - of you': + # - + # - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html + # - + # - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows + # - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify + # -sites that are permitted to frame your own site. + # - + Header always set X-Frame-Options "SAMEORIGIN" + + # - X-Xss-Protection + # - + # - This header is used to configure the built in reflective XSS protection found + # - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header + # - are 0, which disables the protection, 1 which enables the protection + # - and 1; mode=block which tells the browser to block the response if it + # - detects an attack rather than sanitising the script. + # - + Header always set X-Xss-Protection "1; mode=block" + + # - X-Content-Type-Options + # - + # - Nice and easy to configure, this header only has one valid value, nosniff. + # - It prevents Google Chrome and Internet Explorer from trying to mime-sniff + # - the content-type of a response away from the one being declared by the server. + # - It reduces exposure to drive-by downloads and the risks of user uploaded content + # - that, with clever naming, could be treated as a different content-type, like + # - an executable. + # - + Header always set X-Content-Type-Options "nosniff" + + # - Content Security Policy + # - + # - The CSP header allows you to define a whitelist of approved sources of content + # - for your site. By restricting the assets that a browser can load for your site, + # - like js and css, CSP can act as an effective countermeasure to XSS attacks. I + # - have covered CSP in a lot more detail in my blog Content Security Policy - An + # - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/). + # - + # - Here is a basic policy to enforce TLS on all assets and prevent + # - mixed content warnings. + # - + # + Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'" + + # - Referrer-Policy + # - + # - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header + # - field that identifies the address of the webpage (i.e. the URI or IRI) that + # - linked to the resource being requested. By checking the referrer, the new + # - webpage can see where the request originated. + # - + Header set Referrer-Policy "strict-origin-when-cross-origin # - HTTP Strict Transport Security (HSTS) # - @@ -1190,6 +1336,8 @@ cat <> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file # - Header always set Strict-Transport-Security "max-age=31536000" + SSLEngine on + SSLCertificateFile ${APACHE_CERT_DIR}/$APACHE_SERVER_CERT SSLCertificateKeyFile ${APACHE_CERT_DIR}/$APACHE_SERVER_KEY $SSLCertificateChainFile @@ -1214,6 +1362,80 @@ cat <> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file RewriteCond %{HTTPS} !=on RewriteRule (.*) https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L] + # ========== + # - HTTP security Headers + # ========== + + # - X-Frame-Options + # - + # - The X-Frame-Options header (RFC), or XFO header, protects your visitors + # - against clickjacking attacks. An attacker can load up an iframe on their + # - site and set your site as the source, it's quite easy: + # - + # - + # - + # - Using some crafty CSS they can hide your site in the background and create some + # - genuine looking overlays. When your visitors click on what they think is a harmless + # - link, they're actually clicking on links on your website in the background. That + # - might not seem so bad until we realise that the browser will execute those requests + # - in the context of the user, which could include them being logged in and authenticated + # - to your site! + # - + # - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front : + # - of you': + # - + # - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html + # - + # - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows + # - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify + # -sites that are permitted to frame your own site. + # - + Header always set X-Frame-Options "SAMEORIGIN" + + # - X-Xss-Protection + # - + # - This header is used to configure the built in reflective XSS protection found + # - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header + # - are 0, which disables the protection, 1 which enables the protection + # - and 1; mode=block which tells the browser to block the response if it + # - detects an attack rather than sanitising the script. + # - + Header always set X-Xss-Protection "1; mode=block" + + # - X-Content-Type-Options + # - + # - Nice and easy to configure, this header only has one valid value, nosniff. + # - It prevents Google Chrome and Internet Explorer from trying to mime-sniff + # - the content-type of a response away from the one being declared by the server. + # - It reduces exposure to drive-by downloads and the risks of user uploaded content + # - that, with clever naming, could be treated as a different content-type, like + # - an executable. + # - + Header always set X-Content-Type-Options "nosniff" + + # - Content Security Policy + # - + # - The CSP header allows you to define a whitelist of approved sources of content + # - for your site. By restricting the assets that a browser can load for your site, + # - like js and css, CSP can act as an effective countermeasure to XSS attacks. I + # - have covered CSP in a lot more detail in my blog Content Security Policy - An + # - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/). + # - + # - Here is a basic policy to enforce TLS on all assets and prevent + # - mixed content warnings. + # - + # + Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'" + + # - Referrer-Policy + # - + # - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header + # - field that identifies the address of the webpage (i.e. the URI or IRI) that + # - linked to the resource being requested. By checking the referrer, the new + # - webpage can see where the request originated. + # - + Header set Referrer-Policy "strict-origin-when-cross-origin + CustomLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-access.log combined ErrorLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-error.log @@ -1283,7 +1505,79 @@ EOF fi cat <> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file - SSLEngine on + # ========== + # - HTTP security Headers + # ========== + + # - X-Frame-Options + # - + # - The X-Frame-Options header (RFC), or XFO header, protects your visitors + # - against clickjacking attacks. An attacker can load up an iframe on their + # - site and set your site as the source, it's quite easy: + # - + # - + # - + # - Using some crafty CSS they can hide your site in the background and create some + # - genuine looking overlays. When your visitors click on what they think is a harmless + # - link, they're actually clicking on links on your website in the background. That + # - might not seem so bad until we realise that the browser will execute those requests + # - in the context of the user, which could include them being logged in and authenticated + # - to your site! + # - + # - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front : + # - of you': + # - + # - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html + # - + # - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows + # - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify + # -sites that are permitted to frame your own site. + # - + Header always set X-Frame-Options "SAMEORIGIN" + + # - X-Xss-Protection + # - + # - This header is used to configure the built in reflective XSS protection found + # - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header + # - are 0, which disables the protection, 1 which enables the protection + # - and 1; mode=block which tells the browser to block the response if it + # - detects an attack rather than sanitising the script. + # - + Header always set X-Xss-Protection "1; mode=block" + + # - X-Content-Type-Options + # - + # - Nice and easy to configure, this header only has one valid value, nosniff. + # - It prevents Google Chrome and Internet Explorer from trying to mime-sniff + # - the content-type of a response away from the one being declared by the server. + # - It reduces exposure to drive-by downloads and the risks of user uploaded content + # - that, with clever naming, could be treated as a different content-type, like + # - an executable. + # - + Header always set X-Content-Type-Options "nosniff" + + # - Content Security Policy + # - + # - The CSP header allows you to define a whitelist of approved sources of content + # - for your site. By restricting the assets that a browser can load for your site, + # - like js and css, CSP can act as an effective countermeasure to XSS attacks. I + # - have covered CSP in a lot more detail in my blog Content Security Policy - An + # - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/). + # - + # - Here is a basic policy to enforce TLS on all assets and prevent + # - mixed content warnings. + # - + # + Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'" + + # - Referrer-Policy + # - + # - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header + # - field that identifies the address of the webpage (i.e. the URI or IRI) that + # - linked to the resource being requested. By checking the referrer, the new + # - webpage can see where the request originated. + # - + Header set Referrer-Policy "strict-origin-when-cross-origin # - HTTP Strict Transport Security (HSTS) # - @@ -1295,6 +1589,8 @@ cat <> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file # - Header always set Strict-Transport-Security "max-age=31536000" + SSLEngine on + SSLCertificateFile ${APACHE_CERT_DIR}/$APACHE_SERVER_CERT SSLCertificateKeyFile ${APACHE_CERT_DIR}/$APACHE_SERVER_KEY $SSLCertificateChainFile @@ -1662,6 +1958,15 @@ cat <>$WEBSITE_BASEDIR/roundcubemail-${ROUNDCUBE_VERSION}/config/config.in \$config['login_autocomplete'] = 1; +// ---------------------------------- +// IMAP (further settings) +// ---------------------------------- + +// IMAP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or null to use +// best server supported one) +\$config['imap_auth_type'] = 'LOGIN'; + + // ---------------------------------- // USER PREFERENCES // ----------------------------------