Introduction to Web Security: Part 1

[MrLinus]

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:

<?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.

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:

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.

<?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).

[The Duck]

I have a question, you said:

"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"

My question is: what exactly is a directory listing command?? I dont think I have heard that term before. Well maybe I have since it sounds somewhat familiar, but I must have forgotten what it is.

[groovicus]

For linux, that would be 'ls', which would list the contents of the directory, or a list of directories; or the equivalent in Windows would be 'dir'??

Or defined another way, a command, that when entered, would list the contents of the directory...

...that's my story and I'm sticking to it

[MrLinus]

Groovicus hit it on the head. I find that the ls command can look weird by itself and I didn't want to get into explaining what ls was and how it works compared to dir. I figured that is better served in a *nix-command tutorial (and there are a few around here).

[The Duck]

Thanks for the answer guys. But the only way you could get a directory listing using the <b>dir</b> (hope html works ) command was from the command prompt right? like using ftp right?

[MrLinus]

Yes and no. In Windows you can use the Right click to view the Properties of directories. If you are using CLI (Command Line Interface) then it would be the dir. You can, in XP at least, use the dir /q to list the owners of directories and use the cacls.exe to see permissions on the directory.

Side note: replace the <> with [] when posting bold, italic and underline code here.

[The Duck]

What would be the profit of viewing the propeties of directories?? All its showing is the URL of the directory right?

[MrLinus]

What would be the profit of viewing the propeties of directories?? All its showing is the URL of the directory right?

Depends on your point of view. From an attacker's point of view, I can get more information about the person that administers the website. From an admin/web designer point of view, I can look for "information leaks".

[The Duck]

I have heard and read several stories about people or "super l33t h4x0rs" going into a simple directory like www.website.com/images for example and being put under investigation. I guess the reason was that they consider hacking going to a website and from there going to a page that isnt linked. Or I guess hacking techniques. I mean I can see if someone was in a directory like www.website.com/admin and then saw the admin.php/.htm and defaced the site. Or like an article a little while ago I read; it was about someone modifying a URL and it led to the public companies quarterly earnings and posted them on the internet before the company wanted to which is good info to have for inside traders . But for going into a directory as simple as /images???? I mean c'mon!! What do you guys think. I suppose the average everday joe internet user doesnt know anything about directories but...I dont know, I just confused myself now lol

[TheSpecialist]

Well you could do that Indexof: thing in google and there is lots of things you can find *cough "hidden" away in web directories that you wouldn't normally find by viewing their normal pages. And you hear about peaple getting personal information like credit number and passwords pffft.... I'd say that happends RARELY! But on most occasions you can find various lists of peaple places and things, *.txt to do lists, and various READMEs on some of the stuff they have on their servers. Thats enought to build up intel on a attack.

I seriously doupt they could do anything at all about privacy... its public viewing. However some stuff may have copyrights... you never know I mean now days peaple usually get pissed about "owning" what they share then watching it end up on some other guys site. Like hey look what I found! And of course its wrong to take advantage of what you've learned then **** up a web server.