You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Jason Long <ha...@yahoo.com.INVALID> on 2021/02/08 11:23:46 UTC
[users@httpd] Which parameters must be set to solve these Vulnerabilities?
Hello,
I scanned my Apache web server and below Vulnerabilities discovered:
1- Content Security Policy (CSP) Header Not Set
2- HTTP to HTTPS Insecure Transition in Form Post
3- Reverse Tabnabbing
4- Source Code Disclosure - PHP
5- Source Code Disclosure - Perl
6- Sub Resource Integrity Attribute Missing
7- Absence of Anti-CSRF Tokens
8- Cookie No HttpOnly Flag
9- Cookie Without SameSite Attribute
10- Cross-Domain JavaScript Source File Inclusion
11- Incomplete or No Cache-control and Pragma HTTP Header Set
12- Insufficient Site Isolation Against Spectre Vulnerability
13- Strict-Transport-Security Header Not Set
I'm thankful if anyone tell me which parameters and headers must be set and enable in the Apache configuration.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Which parameters must be set to solve these
Vulnerabilities? [EXT]
Posted by Jason Long <ha...@yahoo.com.INVALID>.
Thanks. The console of Chromium show me:
"
Content Security Policy blocks inline execution of scripts and stylesheets
The Content Security Policy (CSP) prevents cross-site scripting attacks by blocking inline execution of scripts and style sheets.
To solve this, move all inline scripts (e.g. onclick=[JS code]) and styles into external files.
Allowing inline execution comes at the risk of script injection via injection of HTML script elements. If you absolutely must, you can allow inline script and styles by:
adding unsafe-inline as a source to the CSP header
adding the hash or nonce of the inline script to your CSP header.
109 directives
Directive Element Source code Status
script-src-elem MyWebsite.com/:12 blocked
style-src-elem MyWebsite.com/:16 blocked
script-src-elem MyWebsite.com/:53 blocked
script-src-elem MyWebsite.com/:70 blocked
script-src-elem MyWebsite.com/:90 blocked
style-src-elem MyWebsite.com/:95 blocked
style-src-elem MyWebsite.com/:198 blocked
script-src-elem MyWebsite.com/:208 blocked
style-src-elem MyWebsite.com/:218 blocked
style-src-attr MyWebsite.com/:327 blocked
style-src-attr MyWebsite.com/:328 blocked
style-src-attr MyWebsite.com/:332 blocked
style-src-elem MyWebsite.com/:430 blocked
style-src-attr MyWebsite.com/:441 blocked
style-src-attr MyWebsite.com/:444 blocked
style-src-elem MyWebsite.com/:467 blocked
...
"
On Monday, February 8, 2021, 09:03:41 PM GMT+3:30, James Smith <js...@sanger.ac.uk> wrote:
Without knowing what your website is we can’t really see what is wrong. Have you used chrome (or whatever browser you are using) developer’s tools to see what is blocked by your content security policy (CSP)
From: Nick Folino <ni...@folino.us> Sent: 08 February 2021 17:30To: users@httpd.apache.orgSubject: Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities? [EXT]
What a great site! It consolidates weak servers for hackers to find easier.
On Mon, Feb 8, 2021 at 11:00 AM Jason Long <ha...@yahoo.com.invalid> wrote:
>
> Thank you for your useful information.
> I checked my server with "https://securityheaders.com/ [securityheaders.com]" and result is:
> https://i.postimg.cc/SsBBtRsT/Header.png [i.postimg.cc]
>
>
> To solve the Content Security Policy, I added below line to "httpd.conf":
> Header set Content-Security-Policy "default-src 'self';"
>
> But after it my web site style messed up! Why?
> How about "Permissions-Policy" ?
>
>
>
>
>
>
> On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti <di...@tuxweb.it> wrote:
>
>
>
>
>
>> Hello,
>> I scanned my Apache web server and below Vulnerabilities discovered:
>
>
> There are many ways of solving those vulnerabilities. Most of them can be fixed patching your
> applications.
>
> As rule of thumb, your application should:
> - not use frames or iframes at all
> - use only HTTPS everywhere, always redirect HTTP to HTTPS
> - disable anything you don't need (eg mod_perl, mod_php, etc)
> - enable Strict-Transport-Security to force all traffic to HTTPS with no failback to HTTP
> - don't use cookies if possible, or setup your cookies with those attributes: secure; HostOnly; HttpOnly;
> SameSite=Lax
> - CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be setted directly by your application and not from apache, if possible
>
> Please consider that enabling one or more countermeasures via configuration file in httpd could make your applications stop working properly if they are not designed accordingly! Please double check any of them and test them in your staging environment before setting them live for production.
>
> Also you should be well confident in all of them before running live, or strange things will happen to your applications and your live debug will be difficult.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Which parameters must be set to solve these
Vulnerabilities? [EXT]
Posted by James Smith <js...@sanger.ac.uk>.
Without knowing what your website is we can’t really see what is wrong. Have you used chrome (or whatever browser you are using) developer’s tools to see what is blocked by your content security policy (CSP)
From: Nick Folino <ni...@folino.us>
Sent: 08 February 2021 17:30
To: users@httpd.apache.org
Subject: Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities? [EXT]
What a great site! It consolidates weak servers for hackers to find easier.
On Mon, Feb 8, 2021 at 11:00 AM Jason Long <ha...@yahoo.com.invalid>> wrote:
Thank you for your useful information.
I checked my server with "https://securityheaders.com/ [securityheaders.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__securityheaders.com_&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=wdWmJLgE03jmtZP3tqGRPpUB4qkMuWeruqE_b5sfP0E&s=MbwJ6qNvWELHTpVLo6hsbKs5u37BsMspqNy_OZScLnQ&e=>" and result is:
https://i.postimg.cc/SsBBtRsT/Header.png [i.postimg.cc]<https://urldefense.proofpoint.com/v2/url?u=https-3A__i.postimg.cc_SsBBtRsT_Header.png&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=wdWmJLgE03jmtZP3tqGRPpUB4qkMuWeruqE_b5sfP0E&s=F8UraKukqS6I4PE0sRXNbZxdTB7o81opex_5vFsIavo&e=>
To solve the Content Security Policy, I added below line to "httpd.conf":
Header set Content-Security-Policy "default-src 'self';"
But after it my web site style messed up! Why?
How about "Permissions-Policy" ?
On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti <di...@tuxweb.it>> wrote:
> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:
There are many ways of solving those vulnerabilities. Most of them can be fixed patching your
applications.
As rule of thumb, your application should:
- not use frames or iframes at all
- use only HTTPS everywhere, always redirect HTTP to HTTPS
- disable anything you don't need (eg mod_perl, mod_php, etc)
- enable Strict-Transport-Security to force all traffic to HTTPS with no failback to HTTP
- don't use cookies if possible, or setup your cookies with those attributes: secure; HostOnly; HttpOnly;
SameSite=Lax
- CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be setted directly by your application and not from apache, if possible
Please consider that enabling one or more countermeasures via configuration file in httpd could make your applications stop working properly if they are not designed accordingly! Please double check any of them and test them in your staging environment before setting them live for production.
Also you should be well confident in all of them before running live, or strange things will happen to your applications and your live debug will be difficult.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org<ma...@httpd.apache.org>
For additional commands, e-mail: users-help@httpd.apache.org<ma...@httpd.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org<ma...@httpd.apache.org>
For additional commands, e-mail: users-help@httpd.apache.org<ma...@httpd.apache.org>
--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Re: [users@httpd] Which parameters must be set to solve these
Vulnerabilities?
Posted by Jason Long <ha...@yahoo.com.INVALID>.
What do you mean?
On Monday, February 8, 2021, 09:00:46 PM GMT+3:30, Nick Folino <ni...@folino.us> wrote:
What a great site! It consolidates weak servers for hackers to find easier.
On Mon, Feb 8, 2021 at 11:00 AM Jason Long <ha...@yahoo.com.invalid> wrote:
> Thank you for your useful information.
> I checked my server with "https://securityheaders.com/" and result is:
> https://i.postimg.cc/SsBBtRsT/Header.png
>
> To solve the Content Security Policy, I added below line to "httpd.conf":
> Header set Content-Security-Policy "default-src 'self';"
>
> But after it my web site style messed up! Why?
> How about "Permissions-Policy" ?
>
>
>
>
>
>
> On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti <di...@tuxweb.it> wrote:
>
>
>
>
>
>> Hello,
>> I scanned my Apache web server and below Vulnerabilities discovered:
>
>
> There are many ways of solving those vulnerabilities. Most of them can be fixed patching your
> applications.
>
> As rule of thumb, your application should:
> - not use frames or iframes at all
> - use only HTTPS everywhere, always redirect HTTP to HTTPS
> - disable anything you don't need (eg mod_perl, mod_php, etc)
> - enable Strict-Transport-Security to force all traffic to HTTPS with no failback to HTTP
> - don't use cookies if possible, or setup your cookies with those attributes: secure; HostOnly; HttpOnly;
> SameSite=Lax
> - CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be setted directly by your application and not from apache, if possible
>
> Please consider that enabling one or more countermeasures via configuration file in httpd could make your applications stop working properly if they are not designed accordingly! Please double check any of them and test them in your staging environment before setting them live for production.
>
> Also you should be well confident in all of them before running live, or strange things will happen to your applications and your live debug will be difficult.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities?
Posted by Nick Folino <ni...@folino.us>.
What a great site! It consolidates weak servers for hackers to find easier.
On Mon, Feb 8, 2021 at 11:00 AM Jason Long <ha...@yahoo.com.invalid>
wrote:
> Thank you for your useful information.
> I checked my server with "https://securityheaders.com/" and result is:
> https://i.postimg.cc/SsBBtRsT/Header.png
>
> To solve the Content Security Policy, I added below line to "httpd.conf":
> Header set Content-Security-Policy "default-src 'self';"
>
> But after it my web site style messed up! Why?
> How about "Permissions-Policy" ?
>
>
>
>
>
>
> On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti <
> dino@tuxweb.it> wrote:
>
>
>
>
>
> > Hello,
> > I scanned my Apache web server and below Vulnerabilities discovered:
>
>
> There are many ways of solving those vulnerabilities. Most of them can be
> fixed patching your
> applications.
>
> As rule of thumb, your application should:
> - not use frames or iframes at all
> - use only HTTPS everywhere, always redirect HTTP to HTTPS
> - disable anything you don't need (eg mod_perl, mod_php, etc)
> - enable Strict-Transport-Security to force all traffic to HTTPS with no
> failback to HTTP
> - don't use cookies if possible, or setup your cookies with those
> attributes: secure; HostOnly; HttpOnly;
> SameSite=Lax
> - CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be
> setted directly by your application and not from apache, if possible
>
> Please consider that enabling one or more countermeasures via
> configuration file in httpd could make your applications stop working
> properly if they are not designed accordingly! Please double check any of
> them and test them in your staging environment before setting them live for
> production.
>
> Also you should be well confident in all of them before running live, or
> strange things will happen to your applications and your live debug will be
> difficult.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Which parameters must be set to solve these
Vulnerabilities?
Posted by Jason Long <ha...@yahoo.com.INVALID>.
Thank you for your useful information.
I checked my server with "https://securityheaders.com/" and result is:
https://i.postimg.cc/SsBBtRsT/Header.png
To solve the Content Security Policy, I added below line to "httpd.conf":
Header set Content-Security-Policy "default-src 'self';"
But after it my web site style messed up! Why?
How about "Permissions-Policy" ?
On Monday, February 8, 2021, 04:58:11 PM GMT+3:30, Dino Ciuffetti <di...@tuxweb.it> wrote:
> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:
There are many ways of solving those vulnerabilities. Most of them can be fixed patching your
applications.
As rule of thumb, your application should:
- not use frames or iframes at all
- use only HTTPS everywhere, always redirect HTTP to HTTPS
- disable anything you don't need (eg mod_perl, mod_php, etc)
- enable Strict-Transport-Security to force all traffic to HTTPS with no failback to HTTP
- don't use cookies if possible, or setup your cookies with those attributes: secure; HostOnly; HttpOnly;
SameSite=Lax
- CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be setted directly by your application and not from apache, if possible
Please consider that enabling one or more countermeasures via configuration file in httpd could make your applications stop working properly if they are not designed accordingly! Please double check any of them and test them in your staging environment before setting them live for production.
Also you should be well confident in all of them before running live, or strange things will happen to your applications and your live debug will be difficult.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Which parameters must be set to solve these
Vulnerabilities? [EXT]
Posted by James Smith <js...@sanger.ac.uk>.
-----Original Message-----
From: Eric Covener <co...@gmail.com>
Sent: 08 February 2021 13:13
To: users@httpd.apache.org
Subject: Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities? [EXT]
On Mon, Feb 8, 2021 at 6:24 AM Jason Long <ha...@yahoo.com.invalid> wrote:
>
> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:
>
> 1- Content Security Policy (CSP) Header Not Set
Read up about these and set an appropriate header
> 2- HTTP to HTTPS Insecure Transition in Form Post
Make sure you don't actively have an http:// request.... use HSTS headers....
> 3- Reverse Tabnabbing
Set rel=noopener
> 4- Source Code Disclosure - PHP
Make sure you make all PHP code be executed by php handler and make sure you have got full PHP tags (<?php ) - rather then the short tab '<? '
Don't log errors to browser
> 5- Source Code Disclosure - Perl
Don't put perl in your htdocs directory - keep it outside
Don't log errors to browser
> 6- Sub Resource Integrity Attribute Missing
See 10
> 7- Absence of Anti-CSRF Tokens
Look at form code - you need to set a cookie and a hidden field in the form
> 8- Cookie No HttpOnly Flag
Add this to your cookie creation statement (note there may be some cases where it is impossible to set this - if you want the client to see this!)
> 9- Cookie Without SameSite Attribute
Add this to your cookie creation statement (note there may be some cases where it is impossible to set this - if you want the client to see this!) and specify exactly which sub-domain gets the cookie not .mydomain.com but server.mydomain.com
> 10- Cross-Domain JavaScript Source File Inclusion
Don't if you do - look at CSP and set "integrity" or only allow from certain sites...
> 11- Incomplete or No Cache-control and Pragma HTTP Header Set
Again look this up - there may be reasons why this isn't set - e.g.
> 12- Insufficient Site Isolation Against Spectre Vulnerability
Look at CORS
> 13- Strict-Transport-Security Header Not Set
Just set it again read docs...
>
> I'm thankful if anyone tell me which parameters and headers must be set and enable in the Apache configuration.
I suggest searching the web for existing explanations/resources. You will also need to address most of these with an understanding of your content.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Which parameters must be set to solve these Vulnerabilities?
Posted by Eric Covener <co...@gmail.com>.
On Mon, Feb 8, 2021 at 6:24 AM Jason Long <ha...@yahoo.com.invalid> wrote:
>
> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:
>
> 1- Content Security Policy (CSP) Header Not Set
> 2- HTTP to HTTPS Insecure Transition in Form Post
> 3- Reverse Tabnabbing
> 4- Source Code Disclosure - PHP
> 5- Source Code Disclosure - Perl
> 6- Sub Resource Integrity Attribute Missing
> 7- Absence of Anti-CSRF Tokens
> 8- Cookie No HttpOnly Flag
> 9- Cookie Without SameSite Attribute
> 10- Cross-Domain JavaScript Source File Inclusion
> 11- Incomplete or No Cache-control and Pragma HTTP Header Set
> 12- Insufficient Site Isolation Against Spectre Vulnerability
> 13- Strict-Transport-Security Header Not Set
>
> I'm thankful if anyone tell me which parameters and headers must be set and enable in the Apache configuration.
I suggest searching the web for existing explanations/resources. You
will also need to address most of these with an understanding of your
content.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Which parameters must be set to solve these
Vulnerabilities?
Posted by Dino Ciuffetti <di...@tuxweb.it>.
> Hello,
> I scanned my Apache web server and below Vulnerabilities discovered:
There are many ways of solving those vulnerabilities. Most of them can be fixed patching your
applications.
As rule of thumb, your application should:
- not use frames or iframes at all
- use only HTTPS everywhere, always redirect HTTP to HTTPS
- disable anything you don't need (eg mod_perl, mod_php, etc)
- enable Strict-Transport-Security to force all traffic to HTTPS with no failback to HTTP
- don't use cookies if possible, or setup your cookies with those attributes: secure; HostOnly; HttpOnly;
SameSite=Lax
- CSP, Anti-CSRF Tokens and Cache-control headers and frameworks should be setted directly by your application and not from apache, if possible
Please consider that enabling one or more countermeasures via configuration file in httpd could make your applications stop working properly if they are not designed accordingly! Please double check any of them and test them in your staging environment before setting them live for production.
Also you should be well confident in all of them before running live, or strange things will happen to your applications and your live debug will be difficult.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org