1. TLS 1.0 enabled
Description:
This web server supports encryption via TLS 1.0. TLS 1.0 is not considered "strong cryptography". TLS 1.0 is not considered "strong cryptography" as defined and required by PCI Data Security Standard 3.2(.1) when protecting sensitive information traveling to and from a website. According to PCI, "June 30, 2018 is the deadline to disable SSL/earlier TLS and implement a more secure encryption protocol, TLS 1.1 or later (TLS v1.2 is highly recommended), in order to meet the PCI Data Security Standard (PCI DSS) for securing payment data.
Impact:
An attacker may be able to exploit this issue to perform man-in-the-middle attacks, as well as decrypt communications between affected services and clients.
Recommended :
It is recommended to disable TLS 1.0 and replace it with TLS 1.2 or later.
Solution:
Nginx Configuration TLSv1.2 or TLSv1.3
First check the openssl version:
openssl version
# Output
OpenSSL 1.0.2k-fips 26 Jan 2017
# Linux Centos 7.9 defaults to the above version, OpenSSL 1.1.1 and above only supports TLS v1.3.
Detecting support for TLS1.2
openssl s_client -connect :443 -tls1_2
Nginx Configuration.
ssl_protocols TLSv1.2.
# Just use 1.2 here
# ssl_protocols TLSv1.2 TLSv1.3; # just use 1.2 here.
2, Nginx access to static pages to display directory listings
Description:
Directory Listing is a Web server feature that displays the contents of a directory when there are no indexed files in a particular site directory. keeping this feature turned on on a Web server can be dangerous because it can lead to information leakage.
Impact:
Users can view a list of all files from the affected directory, which may expose sensitive information.
Example:
Solution:
Directory browsing is not enabled by default in Nginx, if you find that it is currently enabled, you can edit thefile, delete the following two lines:
autoindex on;
autoindex_exact_size on;
Restart Nginx.
3. HTTP Strict Transport Security (HSTS) not implemented
Description:
HTTP Strict Transport Security (HSTS) requires browsers to access websites using HTTPS only. It was detected that your web application does not implement HTTP Strict Transport Security (HSTS) because the Strict Transport Security header is missing from the response.
Impact:
HSTS can be used to prevent and/or mitigate certain types of man-in-the-middle (MitM) attacks
Solution:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload';
# or
add_header X-Frame-Options SAMEORIGIN always;
add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload' always;
# max-age=31536000 specifies the validity period of the HSTS policy, in this case one year. You can adjust the validity period according to your needs.
# includeSubDomains indicates that the HSTS policy will apply to all subdomains.
4. Failure to implement content security policy (CSP)
Description:
Content Security Policy (CSP) adds an additional layer of security to help detect and mitigate certain types of attacks, including cross-site scripting (XSS) and data injection attacks. Content Security Policy (CSP) can be implemented by adding the Content-Security-Policy header. The value of this header is a string that 13 contains policy directives describing the content security policy. To implement CSP, you should define the list of allowed sources for all resource types used by your site. For example, if you have a simple site that needs to load scripts, stylesheets, and images from a CDN that is locally hosted and from the jQuery library, the CSP header might look like this: Content-Security-Policy: default-src 'self'; script-src 'self'Detected that your Web application does not implement Content Security Policy (CSP) because the CSP header is missing from the response. It is recommended that Content Security Policy (CSP) be implemented in your web application.
Impact:
CSP can be used to prevent and/or mitigate attacks involving content/code injection, such as cross-site scripting/XSS attacks, attacks requiring the embedding of malicious resources, attacks involving the malicious use of iframes (e.g., clickjacking attacks), and so on.
Recommended :
It is recommended that you implement Content Security Policy (CSP) in your Web applications. Configuring Content Security Policy involves adding the Content-SecurityPolicy HTTP header to a Web page and assigning it a value that controls the resources that user agents are allowed to load for that page.
Solution:
Adding request headers to the nginx configuration file Content-Security-Policy：
# Add CSP header
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';";";
default-src 'self': Specifies that the default source of resources allowed to be loaded is the current domain ('self'), this is a basic setting to ensure that only resources from the current site can be loaded.
script-src 'self' 'unsafe-inline' 'unsafe-eval': Specifies that the source of JavaScript allowed to be loaded is the current domain, and allows inline scripts and unsafe JavaScript execution methods such as using eval(). Note that 'unsafe-inline' and 'unsafe-eval' are security risks, and it is recommended that they be avoided in favor of strict CSP policies such as external script loading.
style-src 'self' 'unsafe-inline': specifies that the source allowed to load stylesheets is the current domain, and allows inline styles. Again, 'unsafe-inline' should be avoided at all costs and can be made safer by loading from an external CSS file.
# Based on the above information, add the following code
# Add the CSP header
add_header Content-Security-Policy "default-src 'self'; script-src 'self' ; style-src 'self' ; img-src 'self' data: ; font-src 'self' data: ;";.
# Just splice multiple addresses together after a space