Hide Apache and PHP Version and Signatures in Ubuntu Linux

secure-apache
Apache Security

By default, your Apache web server (and PHP if it is installed) will indicate to clients the exact version of the Apache software which is running. This version information can be seen in the HTTP response header.

At times, such behaviour is undesirable as some administrators think that this will make their server more vulnerable to attacks since an attacker will immediately know what software versions are running and may then easily gather any available exploits. The simple fact is, even if your server software is masked, and attacker can try to determine the versions using other means, or they can just try to attack it using all the exploits they have.

Regardless of whatever your intention is, turning off these signatures will add an additional level of complexity (albeit minimal) to a potential attacker.

The tutorial below explains.

How to disable Apache signature

Open the relevant apache2.conf config file:

nano /etc/apache2/apache2.conf

At the end of the file, or at some other sensible location, add the following lines:

ServerTokens Prod
ServerSignature off

Restart your server for the new changes to take effect:

/etc/init.d/apache2 restart

How to disable PHP signature

Open the relevant php.ini config file:

nano /etc/php5/apache2/php.ini

Find the line that says:

expose_php = On

And change it to:

expose_php = Off

Finally restart your server again for the new changes to take effect:

/etc/init.d/apache2 restart

Now your server is a little bit more secure from attackers since it will only indicate that it is an Apache server with no clues as to the version number of the modules which are installed.

Note: Disabling the “Server: Apache” line in the HTTP response header altogether cannot be readily done using configurations (if at all), and will usually have to be done by recompiling the web server binaries. If you are running such a critical application that warrants such extreme measures, this task is left up to you. The bottom line is that if your software is kept up to date, it shouldn’t matter if an attacker knows what type of web server you are running.

Secure Apache from Clickjacking with X-FRAME-OPTIONS

secure-apache
Apache Security

Clickjacking is well known web application vulnerabilities. For example, it was used as an attack on Twitter. To defense Clickjacking attack on your Apache web server, you can use X-FRAME-OPTIONS to avoid your website being hacked from Clickjacking.

The X-Frame-Options in HTTP response header can be used to indicate whether or not a browser should be allowed to open a page in frame or iframe. This will prevent site content embedded into other sites. Did you ever tried embedding Google.com in your website as frame? You can’t because it’s protected and you can protect your’s too.

There are three settings for X-Frame-Options:

  1. SAMEORIGIN: This setting will allow page to be displayed in frame on the same origin as the page itself.
  2. DENY: This setting will prevent a page displaying in a frame or iframe.
  3. ALLOW-FROM uri: This setting will allow page to be displayed only on the specified origin.

How to implement in Apache, IBM HTTP Server?

Add following line in Apache Web Server’s httpd.conf file

Header always append X-Frame-Options SAMEORIGIN

Restart Apache Web Server

Note: This implementation is applicable in IBM HTTP Server as well. You can add above Header parameter in httpd.conf of your IBM HTTP Server instance.

How to implement in shared web hosting?

If your website is hosted on shared web hosting then you won’t have permission to modify httpd.conf. However, you can implement this by adding following line in .htaccess file.

Header append X-FRAME-OPTIONS "SAMEORIGIN"

How to verify the implementation?

You can use any web developer tool to view Response headers and ensure you see following. You can also use online tool – Header Checker to verify.

X Frame Options

Originally posted on http://chandank.com/webservers/apache/secure-apache-from-clickjacking-with-x-frame-options

Secure cookie with HttpOnly and Secure flag in Apache

secure-apache
Apache Security

Do you know you can mitigate most common XSS attack using HttpOnly and Secure flag with your cookie? XSS is dangerous, very dangerous. By looking at increasing number of XSS attack on daily basis, you must secure you web applications.

Without having HttpOnly and Secure flag in HTTP response header, it is possible to steal or manipulate web application session and cookies. It’s good practice to set HttpOnly and Secure flag in application code by developers. However, due to bad programming or developers’ unawareness it comes to Web Infrastructures.

I will not talk about how to set these at code level. You can refer here.

While performing security test on web applications, it’s expected that you will have to fix these to pass the penetration test. This is how you can fix these in Apache Web Server.

Implement in Apache:

1.     Ensure you have mod_headers.so enabled in Apache instance

2.     Add following entry in httpd.conf

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

3.     Restart Apache Web Server

Note: Header edit is not compatible with lower than Apache 2.2.4 version. You can use following to set HttpOnly and Secure flag in lower than 2.2.4 version. Thanks to Ytse for sharing this information.

Header set Set-Cookie HttpOnly;Secure

Verification:

Open your website with HTTP Watch, Live HTTP Header or HTTP Header Online tool.

Check HTTP response header, you should see as highlighted

Cookie Httponly Secure

 

Originally posted by : http://chandank.com/webservers/apache/httponly-secure-cookie-apache

Preventing XSS Attacks

xss-attacks
XSS Attacks

In my last post I explained you what an XSS attack mean in this post I will explain how can we prevent such attacks.

Preventing a webpage from an XSS attack should always be there in your mind.You can better create a function that prevents these attacks and call it everytime.Fortunately its very simple to prevent these attacks.You should never trust a user that he or she will always input proper data.There are millions of attackers sitting online just to find a prey.

Every bit of data must be validated on input and escaped on output. This is the golden rule of preventing XSS.

To prevent attacks we should follow data validation,data sanitization and output escaping.

Data Validation

It is a process where you validate data according to its requirement.Every piece of data must be validated.

Eg : When you want to validate a phone number you should only allow the user to enter numbers and discard strings or characters.And if you want to allow some special characters like “plus”,”brackets” or “dashes” as such characters are also an acceptable phone format you may use a regular expression for same.

<?php
// validates an Indian mobile number
if (preg_match('^((\\+91-?)|0)?[0-9]{10}$', $phone)) {
    echo $phone . " is valid format.";
}

Data Sanitization

Its a process where you clean up the data by removing any unwanted bits.

Eg : You may want to remove all HTML markups from the data.

<?php
// sanitize HTML from the comment
$comment = strip_tags($_POST["comment"]);

Output Escaping

When presenting the data as output via a browser the output should be escaped to protect its meaning.

<?php
// escape output sent to the browser
echo "You searched for: " . htmlspecialchars($_GET["query"]);

Summary

Never trust the data coming from users and take all required actions to prevent such attacks.You can prevent them with Data Validation and Sanitization and also by escaping Output to protect users.

 

 

 

Cross Site Scripting Attacks (XSS)

 

xss-attacks
XSS Attacks

An XSS attack is one of the top most tried out attacks on a PHP enabled system and your PHP script may not be immune.

This attack is made by injection of code via a web form. The code injected can be any malicious client-side code, such as JavaScript, VBScript, HTML, CSS, Flash, and others. The code is used to save harmful data on the server or perform a malicious action within the user’s browser.

Sadly , many developers fails to deliver a secure code thus open to attacks.Every programmer should consider such attacks and vulnerabilities and try to make the program or script free from getting attacked.

Example

Let me give you an example which will explain you how does such attacks happen.

Below is an index.php page with the following code.

<form method="post" action="save.php">
   <input type = "text" name = "name">
   <input type="submit" name="submit" value="Save">
</form>

In the above html code there is a simple form with a textbox and submit button.On click of the button the form is submitted to save.php for further processing.

A genuine user will fillup his/her name but an attacker can inject code instead of name.

Suppose on save.php just prints out the name.

   echo $_POST['name'];

Suppose instead of writing a plane name the attacker inputs <script>alert(‘HaHa You are attacked!!’);</script>.

If the scripts are not filtered the user will see the popup with message “HaHa You are attacked!! “.

Such JavaScript alert messages though are not harmful still are malicious.But think about what could happen in the JavaScript code was written to steal a user’s cookie and extract sensitive information from it? There are far worse XSS attacks than a simple alert() call.

Types of XSS Attacks

  1. Non-Persistent : The kind of attack shown in the above example falls under this category.It means attacks in which the code is not actually stored on the server but is rather presented to the user.
  2. Persistent : This attack is more dangerous one in which the code is actually injected into server.

Summary

Hopefully this article gave you a good explanation of what cross-site scripting attacks are.Never trust data coming from the user or from any other third party sources.In my next post I’ll explain how these attacks can be prevented.