Limit HTTP Request Methods in Apache

Objective

The HTTP 1.1 protocol supports many request methods. Not all of these may be required for your site, and may in fact add a potential risk.

A default Apache configuration supports OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT method in HTTP 1.1 protocol.

However, typically most web applications only need GET, HEAD, POST request methods.

Solution

Disable all HTTP request methods except for GET, HEAD, POST.

Edit your Apache configuration file/etc/apache2/httpd.conf and add the following in the respective Directory directive

<Directory />
    <LimitExcept GET POST HEAD>
        deny from all
    </LimitExcept>
</Directory>

Reload Apache

[root@nowherelan]# systemctl reload httpd.service

Verify that your web application still functions properly after disabling these request methods.

Use the online Request Method Security Scanner to remotely check your site for which HTTP request methods are allowed.

My System Configuration

  • CentOS 7
  • Apache 2.4

References

Remove Server Version Banner in Apache

Objective

To not expose the version of Apache the web server is running, which can aide attackers.

Solution

Go to Geek Flare’s Test Site and check your website’s HTTP Response Header . With a default Apache configuration, the HTTP Response Header will expose Apache’s version and OS

Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips

Edit your Apache configuration file/etc/apache2/httpd.conf and add the following

ServerTokens Prod
ServerSignature Off

TheServerTokens will change Header to only display the web server type

The ServerSignature directive will remove the version information from the page generated by Apache.

Reload Apache

[root@nowherelan]# systemctl reload httpd.service

Check your website’s HTTP Response Header again. Now it should only show

Server: Apache

My System Configuration

  • CentOS 7
  • Apache 2.4

References

Secure Your Site with the X-XSS-Protection HTTP Header in Apache

Objective

X-XSS-Protection is a security header to prevent some level of cross-site scripting (XSS) vulnerabilities.

Solution

Edit your Apache configuration file/etc/apache2/httpd.conf and add the following to your VirtualHost.

# Load the headers module
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
    # X-XSS-Protection
    Header set X-XSS-Protection "1; mode=block"
</VirtualHost>

With a value of “1; mode=block” XSS filter will be enabled will prevent rendering the page if an attack is detected.

Reload Apache

[root@nowherelan]# systemctl reload httpd.service

Go to Geek Flare’s Test Site and test your site . The output will tell you if you have everything correct.

My System Configuration

  • CentOS 7
  • Apache 2.4

References

Secure your WordPress site with the Content Security Policy (CSP) HTTP Header in Apache

Objective

Content Security Policy (CSP) is a HTTP security header to prevent cross-site scripting, clickjacking, and code injection attack.

CSP instruct browsers to load content only from allowed sources. It helps you to restrict the sources and types of content that may be loaded and processed by visitor browsers.

Solution

Edit your Apache configuration file/etc/apache2/httpd.conf and add the following to your VirtualHost.

Below is a good starter policy for a site. It allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load (i.e., object, frame, media, etc).

# Load the headers module
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
    # Content-Security-Policy Header
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';"

</VirtualHost>

However, you will need to customize this to meet your specific needs. Use the Chrome browser developer tools console to display blocks encountered by your browser. You may also want to disable browser extensions during your testing to avoid issues.

Below is a good starter policy for a WordPress site. It allows images, scripts, AJAX, and CSS from the same origin, and other resources to load only from specifically named sites.

# Load the headers module
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
    # Content-Security-Policy Header
    Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: http: https: *.gravatar.com *.wp.com *.wordpress.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' http: https: *.wp.com *.wordpress.com; style-src 'self' 'unsafe-inline' http: https: fonts.googleapis.com *.wp.com *.wordpress.com; font-src 'self' data: http: https: fonts.googleapis.com themes.googleusercontent.com *.wp.com *.wordpress.com; frame-src 'self' 'unsafe-inline' 'unsafe-eval' http: https: *.wp.com *.wordpress.com"
</VirtualHost>

Reload Apache

[root@nowherelan]# systemctl reload httpd.service

Go to Geek Flare’s Test Site and test your site . The output will tell you if you have everything correct.

My System Configuration

  • CentOS 7
  • Apache 2.4
  • WordPress version 5.0

References

Secure MIME Types with X-Content-Type-Options in Apache

Objective

Every resource served from a web server is associated with MIME type (also called content-type).

There is a possibility to execute style sheet and steal content from another site through content type doesn’t match.

You may prevent this vulnerability in Internet Explorer or Google Chrome by adding “nosniff” in the header.

Add X-Content-Type-Options header in Apache to reduce MIME types attack risk.

Solution

Edit your Apache configuration file/etc/apache2/httpd.conf and add the following to your VirtualHost.

# Load the headers module
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
    # Secure MIME Types with X-Content-Type-Options
    Header set X-Content-Type-Options nosniff
</VirtualHost>

Reload Apache

[root@nowherelan]# systemctl reload httpd.service

Go to Geek Flare’s Test Site and test your site . The output will tell you if you have everything correct.

My System Configuration

  • CentOS 7
  • Apache 2.4

References

Implement X-FRAME-OPTIONS in HTTP headers to prevent Clickjacking attacks in Apache

Objective

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

Solution

Edit your Apache configuration file/etc/apache2/httpd.conf and add the following to your VirtualHost.

# Load the headers module
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
    # X-Frame-Options to prevent clickjacking attacks
    Header always append X-Frame-Options DENY
</VirtualHost>

Reload Apache

[root@nowherelan]# systemctl reload httpd.service

Go to Geek Flare’s Test Site and test your site . The output will tell you if you have everything correct.

My System Configuration

  • CentOS 7
  • Apache 2.4

References

HTTP Strict Transport Security (HSTS) In Apache

Objective

HTTP Strict Transport Security (HSTS) is a security feature that lets a web site tell browsers that it should only be communicated with using HTTPS, instead of using HTTP. This tutorial describes how to set up HSTS in Apache.

HSTS addresses the following threats:

  • User bookmarks or manually types http://example.com and is subject to a man-in-the-middle attacker
    • HSTS automatically redirects HTTP requests to HTTPS for the target domain
  • Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP
    • HSTS automatically redirects HTTP requests to HTTPS for the target domain
  • A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate
    • HSTS does not allow a user to override the invalid certificate message

Solution

A minimum of Apache version 2.2.22 is needed to support HSTS.
Edit your Apache configuration file/etc/apache2/httpd.confand add the following to your VirtualHost. You have to set it on the HTTPS VirtualHost, and not in the HTTP VirtualHost .

# Load the headers module
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
    # HSTS (31536000 seconds = 1 year)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

Once a web browser has been to the site once and received the header it will remember that the site should only be accessed over HTTPS for the duration of the max-age value. This value is reset every time the site is accessed.

To always redirect your visitors to the HTTPS version of your website, use the following configuration:

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Reload Apache

[root@nowherelan]# systemctl reload httpd.service

Go to SSL Labs Test Site and test your site. The output will tell you if you have everything correct.

My System Configuration

  • CentOS 7
  • Apache 2.4

References