Apache HTTP Server Security Practices

Apache HTTP server is the widely used webserver software for web applications.It was estimated that 50% of global websites are served by Apache HTTP Server.Having apache security practices point in place will helps us to keep our web application secure and safe.

Top 10 apache http server security settings:

1-Selecting Secure Protocols

Insecure protocols (SSLv2, SSLv3 and TLSv1.0) will allow a man-in-the-middle attacker to guess the plaintext being encrypted. If an attacker can predict the IVs (initialization vector) and examine the encrypted data, he will be able to make guess about the encrypted sensitive plaintext, by examining enough encrypted data can eventually uncover the value of the user sensitive information or alter user records, and to perform transactions on behalf of user. SSL Protocol -all +TLS1.1 +TLSv1.2The above apache setting will disable all insecure SSL/TLS versions such as SSLv2, SSLv3, and TLSv1.0. And only enables the secure TLSv1.1 & TLSv1.2 protocols.

2-Selecting Secure Cipher Suites

SSL cipher suites define the level of secure communication between client and the server.  Weak cipher suites will allow an attacker to decrypt the secure communication between the client and the server, or successfully execute a "man-in-the-middle" attack on the client, enabling him to view sensitive information and perform actions on behalf of the client.

 

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

 The above apache settings will disable all weak ciphers such as !ADH, !NULL, !EXPORT, !RC4, !3DES.Use only strong cipher suite such as AES128, AES256.

3-Use Secure Cookie attribute & HttpOnly Cookie attribute

Both secure and HttpOnly cookie attribute will keep cookie information secure, will not reveal the cookie to a third party or unsecure sites.The secure cookie attribute will allow client to send cookies only to HTTPS pages. In another way, it will restrict client to send a cookie over an unencrypted HTTP pages. If cookie does not contain the "secure" attribute, does not have restriction may be sent to the site during an unsecure HTTP pages as clear text. Any information such as cookies, session tokens or user credentials that are sent to the server as clear text, can be stolen by attacker and used later for identity theft or user impersonation.

The HttpOnly cookie attribute will mitigate the risk of client side script accessing the cookie information. If cookie does not contain the "HttpOnly" attribute, does not have restriction can be accessed through client side script. As a result, the cookie (typically our session cookie) becomes vulnerable to theft and used later for identity theft or user impersonation. Header edit Set-Cookie^(.*)$ $1;HttpOnly;Secure

4-Disable Directory Listing

Apache directory listing will allow the attacker to view and download the contents of certain web application virtual directories, which might contain restricted files. An attacker can use this functionality to aid in finding hidden file processes on the directory and potentially gather further sensitive information. Options –Indexes

5-Disable Apache Multi view

Apache has a feature called Multiviews, which is oftentimes turned on by default on certain directories. If we don't know the extension of a file on the server, we can request for the file without the extension. Apache will then respond the file with the appropriate match.The vulnerability is that if an attacker request a file, and write an invalid mime type, Apache will respond you with all the options. It will lead an attacker to exploit the entire directory.

Options  -MultiViews

6-Enable Cross-Frame Scripting Defense

Cross-Frame Scripting is an attack technique where an attacker loads a vulnerable application in an iFrame on his malicious site. The attacker can then launch a Click jacking attack, which may lead to Phishing, Cross-Site Request Forgery, sensitive information leakage, and more.The X-Frame-Options HTTP response header is used to determine a browser should be allowed to render a website in a <frame>, <iframe> or <object>.X-Frame-Options SAMEORIGIN: It is Cross-Frame Scripting Defense header allows the pages can only be displayed in a frame on the same origin as the page itself. Header always append X-Frame-Options SAMEORIGIN.

 7-Enable Content-Security-Policy header

The "Content-Security-Policy" header is designed to modify the way browsers render pages, and thus to protect from various cross-site injections, including Cross-Site Scripting.  It is important to set the header value correctly, in a way that will not prevent proper operation of the web site. For example, if the header is set to prevent execution of inline JavaScript, the web site must not use inline JavaScript in its pages. “Header always set Content-Security-Policy "default-src 'self';"         

8-Enable HTTP Strict-Transport-Security Header

HTTP Strict Transport Security (HSTS) is a mechanism which protects secure (HTTPS) websites from being downgraded to non-secure HTTP. This mechanism enables web servers to instruct their clients (web browsers or other user agents) to use secure HTTPS connections when interacting with the server, and never use the insecure HTTP protocol.

The HTTP Strict Transport Security policy is communicated by the server to its clients using a response header named "Strict-Transport-Security". The value of this header is a period of time during which the client should access the server in HTTPS only. Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

9-Enable X-Content-Type-Options header

The "X-Content-Type-Options" header (with "nosniff" value) prevents IE and Chrome from ignoring the content-type of a response. This action may prevent untrusted content (e.g. user uploaded content) from being executed on the user browser. Header always set X-Content-Type-Options nosniff

10-Enable "X-XSS-Protection" header

The "X-XSS-Protection" header forces the Cross-Site Scripting filter into Enable mode, even if disabled by the user. This filter is built into most recent web browsers (IE 8+, Chrome 4+), and is usually enabled by default. Although it is not designed as first and only defense against Cross-Site Scripting, it acts as an additional layer of protection. Header always set X-XSS-Protection 1

 

Authored By Saravanan Sivaraman

TCS Enterprise Security And Risk Management

Rate this article: 
Average: 3 (7 votes)
Article category: