Apache web server is one of the most popular web servers in the world. Its development was started in early 1995 and it quickly began to play the dominant role in the initial growth of the internet. Apache currently holds 25.74% of market share as per the netcraft December 2017 survey.
This week CloudPassage released new policy templates for Configuration Security Monitoring (CSM), based on the CIS Benchmarks for apache-httpd versions 2.2 and 2.4. These CSM templates can help make the apache-httpd server more secure. Our CSM template for apache-httpd ver. 2.2 is based on CIS Apache HTTP Server 2.2 Benchmark v3.4.1, and the CSM template for apache-httpd ver. 2.4 is based on CIS Apache HTTP Server 2.4 Benchmark v1.3.1. Please keep in mind that new CSM policies templates are applicable to rpm-based apache-httpd server with default set of binary and configuration files.
While developing the template I came across an interesting feature called Content Security Policy (CSP), which can help reduce the risk of XSS attack. The main idea of this feature is to transmit in an HTTP response header a whitelist of sources. (A response header is an HTTP header that can be used in an HTTP response and that doesn’t relate to the content of the message.) These sources are for trusted content and instruct the browser to only execute or render resources from those specific sources. In case of an attack (even if an attacker succeeds in code injection) the browser will not execute or render this code, because it will not be a code from a trusted source.
However, CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding. You can find detailed documentation under this link.
So how does it work? This technology is based on transmitting additional information in the HTTP response header. Response headers, like Location or Server are used to give a more detailed context of the response. You can use, for example, Firefox Network Monitor from Developer Tools to view response header.
To demonstrate, I created a simple website with an image from an external source and inspected the HTTP response header using Firefox. As seen below, the image loaded successfully l (Figure 1) and there aren’t any errors in the Firefox Web Browser’s console when using default apache-httpd web-server settings (i.e. when no CSP policy is defined).
Figure 1: Example image successfully loaded (no CSP)
To enable CSP, edit the apache-httpd config file located at /etc/httpd/conf/httpd.conf and added:
Header unset Content-Security-Policy
Header set Content-Security-Policy “default-src ‘self’;”
After restarting the web server, you will then see the following as shown in Figure 3:
Figure 3: HTTP header after enabling CSP
The image does not load because the source in which the image is located was forbidden in the CSPas shown in Figure 4. This is a simple example that demonstrates the CSP.
Figure 4: Image is blocked due to the CSP
Please keep in mind, that the CSP can be configured in multiple different ways: by adding global settings in the configuration file, by adding settings in <Virtualhost> section, by adding settings in .htaccess files, and by adding settings using php and more.
So when using CSM, you can only check if the settings are added globally. Using the CSM Halo functionality, you can check on CSP as shown below in Figure 5:
Figure 5: Checking for a CSP using Halo
The Content Security Policy (CSP) is a great way to reduce the risk of Cross Site Scripting attack. With CSP you can effectively disallow inline scripts and external scripts from untrusted sources. You define the policy via an HTTP header with rules for all types of assets. More information is available in the content security policy reference, the content security 1.0 page, and content security policy level two will help you check your browser’s compatibility with CSP.