Web 2.0 Entrepreneur

How to hide your Apache and PHP version number

• Posted by Tengku Zahasman on January 15th, 2008 filed in Tutorial, Security, System Administration


• 4 Comments »
• (1,356 Views)

One of the most basic security practice in the web application world is to hide your web server’s software version number. It doesn’t matter if you use Apache 1.3.37 or lighttpd 1.4.10 on a Linux machine or IIS-5.0 on Windows, hiding the version number is crucial if you want to mitigate the risk of your server being attacked by troublemakers.

BEFORE TREATMENT:

AFTER TREATMENT:

Version numbers are the first thing a typical hacker will look for if they want to attack your server. This is because once they know what version your web server is running on, they can easily look for what kind of vulnerabilities are associated with that version, and then simply run the related exploit to hack your server. Attackers can easily know the type and version of your webserver by looking at the HTTP response headers received after they send requests to your application through a Telnet program, or by using Firefox addons/extensions like ServerSpy and Live HTTP Headers in order to see your web server’s version the moment they visit your site.

So hide your Apache and PHP version!

In order to do this, you need to do some sys admin job. I am going to specifically focus on Apache and PHP because I am more of a LAMP (Linux + Apache + MySQL + PHP) user. If you use ASP on Microsoft IIS, I can’t help you much with all these version-hiding thingy (but hey, Google is there to save your day! )

So here goes..

Hide Apache version number:

• Open your Apache’s httpd.conf file (in my case, # vi /usr/local/apache/conf/httpd.conf), and look for the line that says: “ServerSignature On“
• Change it to “ServerSignature Off” (this will hide the Apache version normally seen at the bottom of your 404 error pages)
• Then add “ServerTokens Prod” below that line (to hide the version in HTTP response headers)
• Restart your HTTP service (# /etc/init.d/httpd restart)
• Done! No more Apache version numbers

Hide PHP version number:

• Find your php.ini file (in my case, # vi /usr/local/lib/php.ini), and look for the line that says: “expose_php On“
• Change it to: “expose_php Off“
• Restart your HTTP service if necessary
• Done! No more PHP version number in your HTTP response header

Wasn’t that hard now, was it? Just a few tweaks can save you a great deal of security risk, and may save you your business too! Bear in mind that this does not in any way protect from real vulnerabilities that may be associated with your version. Patches or upgrades should still be applied. However, hiding the version numbers will at least make the hackers life harder

Securing your Web Application

• Posted by Tengku Zahasman on July 9th, 2007 filed in Web App Development, Security


• 3 Comments »
• (371 Views)

Apart from ensuring code performance, there’s something quite bothering when you’re developing a web application and that is to constantly ensure (while writing the application) that your codes are hack-proof to the black hats out there. As a person who works full-time in the Internet security industry, I analyze the security of our client’s web application almost on a daily basis. I study the structure of their application, identify any obvious or hidden vulnerabilities, and then try to poke into them and see if I can hack their web application. This is called a Web Application Testing.. and depending on how deep I am allowed to dig in, it’s sometimes also considered as Penetration Testing.

In most cases, the security holes are obvious. Most of the problem lies on the carelessness (or laziness) of the web developer in developing the application or maybe they just don’t care so much about their application security due to tight deadlines for completing the web app. However, having your web app to be compromised is not something you’d like to see in the long run so it is always a good idea to make sure your application is practising good security measures from the day it is being developed.

There are a few obvious web attacks that you need to be aware of such as SQL Injection, Session hijacking, Bruteforce attack, Buffer Overflows, Cross-site Scripting (XSS) and Cross-site Request Forgery (CSRF). We’ll discuss about those in detail some other time. For the time being it is important to realise that 80% of the time the problem lies on the failure to sanitize or filter out user input from URLs, hidden fields and forms. Sanitizing/filtering user input means processing the user input first instead of using them straight away in the system. This way you can make sure that the input you’re passing around your application is not malicious to the system. If you don’t process the user input first, hackers can easily inject codes into your system and do bad things.

So where do we need to be extra careful about security when writing your code?

1. Forms - Any forms. Search forms. Login forms. Registration forms. Subscription forms. All of them accepts user inputs, and that means they are open doors for hackers to inject malicious codes or SQL statements. Escape any unwanted inputs like quotes (”) or convert them into HTML-equivalent strings (eg: ” to &quot;). Strip any HTML tags like <script> and ensure that the stripping algorithm is good enough to disallow hackers to get around it. Don’t just validate the user input on the client side, process it as well on the server side. Never trust that your users are following the rules.

2. Dynamic URLs - The same rules apply when you accept inputs on the URL. Always strip and escape unwanted inputs (”escape” means adding slashes to the malicious character; like ” to \”). If a user puts in weird characters, make sure your application knows how to handle it and display the appropriate errors instead of spitting out database errors or code errors.

3. File Uploads - Be extra careful on this function if you provide one. If your application can’t properly filter out unwanted files, hackers can easily upload malicious scripts and run it on your web server. It is pretty easy for people to gain control over your web application if they’re allowed to upload dangerous scripts or “backdoored” files into your web server.

There are of course many other ways for hackers to compromise your web application, but I’d like to be general for this time.