Introduction to Web Security: Part 1
Introduction to Web Security
In the beginning...
In the beginning, there was the ARPA. And it was good. Then they said, let there be more than networks. So there was email. And it was good. And then they said we need more than just individual messages, we need to tell all, so there was WAIS. And it was good. And then they said, we want to be creative. So then there was the Web. And it was good. And then they said, it is boring to read text, we want to be more creative. So then there was "web-with-dancing-hamsters-and-loud-midi-music-24-7-and-ads-and-spyware". And it was just weird. Ok. So maybe that's not exactly how the Internet, and specifically that thing we call the World Wide Web (or Weeeb as some pronounce it). But one thing is for sure: no one really thought about security when they clamoured for more creativity.
For many webdesigners, the goal is to make a website sexy and appealling to the general public. That is usually the first thing considered when designing a website. But along with that should be consideration for security. Part of this is the risks that some web applications open up. The site may be sexy but doesn't remain so when it's been defaced because a webdesigner decided to open up all permissions. This tutorial -- and further ones that I will write up -- will look at a variety of issues that face webdesigners and their websites, as well as practical methods of dealing with those issues. While this one may be a general information tutorial it does provide some of the important understand of why practices and procedures are needed to ensure good website security along with good website design.
The Website Components..
First thing we need to do is set the stage to understand what the issues are. For the web environment we have a few areas of concern: the webserver, the web application and the database server (optional -- depends on the website setup).
Before getting into specifics of securing each, let's define each part of the "Web Site Experience". The webserver usually is one of two products: Apache or IIS. Based on Netcraft's Web Server Survey ( April 2004) roughly 67% of all servers are Apache and 21% IIS. Certainly the IIS products would be on a Windows platform (today primarily on Windows 2000 and NT 4). Apache is still dominated by various *nix and Linux products, although some are found on the Windows environment.
The web application is basically a software application that is accessible using a web browser or some type of HTTP(s) user agent. You could even use telnet if you wanted (although not entirely effective). Often our web applications are built with a basis of HTML and added scripting languages to it. The more common languages today include (but not limited to) PHP, Perl, ASP, VBScript, Javascript, ActiveX and Java. Add to this items like Flash and Shockwave, and you have a busy, complicated environment. It is often the web application that opens up the possibility for attacks like directory transversals, SQL injections and other "unwelcomed" activities.
Behind the web application is usually the database. It is in the database that our critical information is often stored, from forum postings to user's logins to personal data of users. Databases come in all shapes and sizes. Our most common general non-profit database seems to be MySQL. The biggest for profit database by far still is Oracle although MySQL is certainly challenging that. SQL as a language is pretty much the same insofar as commands are concerned.
"Ya ya, but I have nothing to steal. Why should I worry about it.. "
What's that I hear you say? You have nothing important to "steal"? How about your website's image? Or the resources and time you spent developing the website? Or your image? These intangibles are often the "things" that get damaged when a website is compromised, defaced (or worse) and the public is aware of it. So, let's look at some of the risks that can affect these various components. The question most often asked is: how do they do this? Well, the steps are straighforward. Attackers generally follow variations of this:
- - identify the server's role
- determine the operating system and version
- determine the operating system and patch level
- scan for open ports (beyond the obvious port 80/443)
- record the web server type, patch level and additional components
- research known vulnerabilities.
Loose lips sink ships
The biggest practice that website designers/administrators can do is limit the amount of information they provide to attackers. While the practise of "security through obscurity" is often downplayed, there is no need to make it easier for attackers to gain information about the server or web application. Customize 404 pages so that they do not provide information like what the server type is, what version it is, etc. or "spoof" the information. There is no Apache 6.6.6 but it might be enough to keep a script kiddie busy for a while. Additionally, change default errors pages for the web application itself. Avoid allowing full paths to appear in the error pages that are presented. As an example (and keep in mind that I'm a PHP-preferrer so you'd need to translate this according to your own prefences) often in many web applications a method is created to connect to the database once, usually in the form of a connect_db.php. Usually it looks like this:
Code:
<?php
$database_connect = @mysql_connect("localhost", "root", "password") or die (mysql_error());
php?>
Unfortunately, something like this gives out too much information. As you can see, an attacker gets an idea of the path layout plus tells me the sql database type based on the error presented.
Code:
Parse error: parse error in /users/msmittens/dumdumdb.php on line 2
It can go from simple information leak to major information leak as presented below:
Code:
Access denied for user: 'root@localhost' (Using password: YES)
Now the attacker knows the name of the user I'm using to connect to the database.
However, if I'm smart, I can alter the script so that instead of the standard error it can give a limited error.
Code:
<?php
$database_connect = @mysql_connect ("localhost", "root", "password") or die (print "Uh oh. Database connection problems");
php?>
So stop giving so much information out to the attackers and making their job easier. Files like this should be in controlled directories with permissions (these are *nix permissions but you can create equivalent restrictive IIS permissions) that limited the ability to browse through the directory. There is no need to view the contents of a directory by any user. 701 (or rwx-----x) should be the default permissions. This allows access into the directory but doesn't allow people to do a directory listing command. Avoid allowing uploads or, if uploads must be done, put them in a seperate area, again with controlled access (703 or rwx----wx) whereby users can upload and enter directories but not see what is there. A script can be created to indicate that an upload is complete.
Open Seseame.. errr.. Sizeseme? Pretty please?
Lastly, in our attempt to stop making things easier for the attacker, make passwords more difficult. It never ceases to amaze me how many people still use password as their password. Or they use the defaults like root/no password for MySQL and scott/tiger for Oracle. Change the default root password to something and use a regular user account in the database area that has limitations as to what powers they have in the database structure itself. Never give more access than is necessary. This user should be limited to only affecting their database (INSERT, DELETE, CREATE, etc.).
Creating strong passwords is actually straightforward. Some tricks to good password policies:
- - don't use dictionary words (any word found in the dictionary)
- don't use your name, nickname, any identifying numbers, birthdate, favourite team, children's names, spouses/partner's names, pets' names, etc. or variations thereof
- do use UPPER and lower case characters, numbers and special characters
- keep in mind the longer the password, the harder it is to break.
- use a passphrase. Passphrases are often easier to remember (thus avoiding the creation of a sticky garden). As an example (please do not use this one): 2bR!=TuB? ("To be or not to be, that is the question" -- Shakespeare).
- realize that no matter what password you use it is still at risk to bruteforce so change passwords regularly (every 3 months for example).
- Avoid using passwords from other websites/forums that you visit. If your password is compromised there then it could compromise your latest creation.
I hope this helps in encouraging you to think about security when designing your websites and to add of these practises to your day-to-day. I will add to this "discussion" hopefully over the next few months.
If you have questions, do not hesitate to contact me.
Note: I had originally created this for a website forum dedicated to webdesigners. Being the only security geek there, I kinda feel that they need to look at security a little more. As I post more tutorials in regards to this for them, I'll add them here for those that might benefit from them (albeit they might be a bit basic in some regards).
