Configuring Apache to avoid common vulnerabilities in web applications
Apache is a web server consisting of several patches (as goes the pun, a patchy) which provides us a flexible, customisable and highly scalable way of serving the content over internet. It’s basically a set of modules (patches) ranging from security, authentication, authorisation up to very basics of logging and configuration. The following article is a take on configuring apache for the trivial loopholes of the server which may lead to severe vulnerabilities. As apache is highly customisable to the needs, it requires a very few lines of configuration to close the vulnerabilities and safeguard the application for possible attacks. So let’s dive in to what are the vulnerabilities and how the apache configuration can be used to plug them.
Click Jacking: Also known as UI redress attack, through which a web user is baited into clicking something different from what user perceives they are clicking on. A simple way to achieve this is by embedding a simple script into a page that opens a iFrame with exact same layout as the original user login page. Or more simply, by putting an invisible button over the visible original button. Once user clicks on the invisible button, the username and password can easily be stolen. A simple solution would be to accept request from verifiable sources only.
X-Frame-Options: ALLOW-FROM https://example.com/
OR
<IfModule mod_headers.c>
Header always set X-Frame-Options SAMEORIGIN
</IfModule>
Cross Site Request Forgery (CSRF): CSRF is a method by which attacker uses a malicious website causing user’s web browser to perform unwanted action on a trusted site for which the user is currently authenticated. Though the solution to this problem lies with using CSRF tokens verification and checking headers to verify the request is from same origin. At the apache level, we can set server signature off and server tokens to product only by editing the httpd.conf file or apache.conf file:
ServerSignature Off
ServerTokens Prod
AND
<IfModule mod_headers.c>
Header unset Server
Header always unset X-Powered-By
Header unset X-Powered-By
Header unset X-CF-Powered-By
Header unset X-Mod-Pagespeed
Header unset X-Pingback</IfModule>
Host Header Injection: A host header is used when several web applications are deployed on the same IP address. Host header specifies which web application will process incoming HTTP request. The host header is set on the user end, hence the server needs either a strict whitelist of the hosts or we unset the host header from apache configuration. A simple example of host header injection could be, is I’m using _SERVER[‘HOST’] in my code to fetch the relative file path.
<script src=”http://<?php echo _SERVER[‘HOST’] ?>/script.js”>
To fix the host header injection we can unset the host header as follows:
<IfModule mod_headers.c>
Header unset X-Forwarded-Host
</IfModule>
For a complete list of vulnerabilities please visit this link. It presents us with a detailed view of year wise distribution of vulnerabilities specific to apache version.
