SnEafer
Senior Member
- Apr 1, 2009
- 154
- 2
The purpose of this article is not to teach you how to hack sites, but to show you some scenarios that may reveal to you how vulnerable your existing site may be, or will hopefully help you prevent any future sites from having these vulnerabilities.
Unfortunately, hacking today is a fact of life. But not all hackers are bad hackers; in fact the term hacker can describe anyone who is enthusiastically interested in computers or programming.
The original hackers, the first ever known, are reported to be a group of model railroad enthusiasts who, sometime in the 1950's were given some old telephony equipment as a donation.
Not wanting to waste this equipment, they 'hacked' or modified it for use in their railroad system and were able to 'dial in' track switching commands using recycled dialers and other parts of the phone equipment. So the original term hacking also meant to modify or exploit a previously unknown use of something.
Punch-card computer systems were soon the subject of hacking, and programmers delighted in finding ways of doing the same things with fewer punch cards. It was shortly after this, sometime in the early seventies, that malicious hacking began to come about in the form of phreaking, hacking into telephone networks and having telephone usage charged to other people or not at all.
Today the terms hacking and hackers have many connotations, the best known being of course people who exploit software and/or the Internet for personal gain or fun.
These hackers are sometimes referred to as black-hat hackers, or crackers, and those that simply use software to hack, with no real programming knowledge are called script-kiddies.
There is also an increasing number of so-called white-hat or ethical hackers who, among other things, use their skills to test web applications for weaknesses and to help develop security in web applications and software. Often, people who look at opensource softwares and attempt to refine and add to its existing features are referred to as hackers.
The purpose of this article is not to teach you how to hack sites successfully; I won't be teaching you how to steal credit card numbers, bring down Hotmail or reverse-engineer the latest release of Windows.
I'm simply going to show you a couple of scenarios that may reveal to you how vulnerable your existing site may be, or will hopefully help you prevent any future sites from having these vulnerabilities. Don't be fooled however; the iron-clad security needed by some sites such as online banks requires the highest degree of professional assistance.
Countless books have been written on the subject of hacking, so there is no possible way for me to discuss all known types of attack. There are some techniques you can try out to attempt to assess the vulnerability of your own site and applications, techniques that once learned, you should
Malicious hacking often takes primarily two things, time and software. This means that most web sites or applications are vulnerable in some way. But it also means that most weaknesses can be protected by time and applications; for example, in the context of hacking, the difference between a five-digit password and an eight-digit password including a number is approximately 22,000 years.
I mean by this that it would take a hacker, using some kind of dictionary attack program around 22,000 years to find your password if it was eight alphanumeric characters.
As a standard rule of thumb, enforce your users into creating passwords of at least 8 characters in length and ask them kindly not include words found in the dictionary. This is for your site's protection as much as their own and that of their fellow users.
Web Forms
Web forms are an easy target for hackers or anyone who simply wants to break your applications, as the user is given the opportunity to pass information to your web server, which performs calculations using that information. If you have any forms on your site, (which you undoubtedly will) visit one of them now and in the first text input field you come to type:
HTML:
<b> I could use this field to execute a script</b>
I could use this field to execute a script
Okay, so you'll probably have some kind of form validation implemented to prevent fields in your forms being left blank, but you can see what I'm getting at here. You just hacked your own form, albeit in a very basic way.
Fortunately, there is a very simple php function which prevents this from happening: HTMLSpecialChars.
It's a function that is usually used in conjunction with mySQL database queries, but can be put to work in form processing php scripts as well.
Let's say, for example, that the first text input field on your HTML form captures visitors' names and is called 'name'. This would be assigned the variable '$name' in the php script that's invoked when the submit button is pressed. All you need to do to prevent code execution on your forms is include:
$name = HTMLSpecialChars($name)
somewhere near the top of the php file. Repeat the above example, and the text should be displayed normally. It won't prevent hackers from trying to hijack your applications, in the same way that locking your car won't prevent it from being stolen, but it's a function that should be included in any form processing script you write as a basic security consideration.
If your site uses multiple forms, in a shoppingcart for example, it will probably rely upon hidden fields to transfer information from one page to the next (often referred to as persistence).
You'll find that if you save the source code of a page containing hidden forms, you can modify the values of hidden forms and then reload the modified page in your browser.
Try experimenting this with some of the simpler forms you use that contain hidden fields; if you've been successful, not only have you hacked your own site again, but you've highlighted the fact that others can do this too.
This is an open door to hackers, especially in the case of shopping carts; what would happen to your business if a hacker were able to use the above technique to change the price of all of your products to $1?
One way around this would be to use a one-way hash such as md5 to generate an outgoing message digest containing a concatenated string of all the hidden field names and values plus a secret key. When the form is submitted, it contains an incoming form digest which is also a concatenated string of all hidden field names and values plus the secret key.
If the outgoing digest differs from the incoming digest, the hidden field values have been tampered with. An easier, but admittedly slightly less secure method of preventing hidden field manipulation would be to use an html encryption tool on pure html pages, thus hiding the names and values of any field names.
Closely related to hidden field manipulation, buffer overruns are engineered in a similar fashion; any text input field with a maxchar=n property can be used to potentially shut down the server. The source code can be accessed, and the maxchar property removed. The hacker then enters, say, 10,000 ones and submits the form.
What happens next? The server shuts down, taking your business with it. A semi-secure solution to this would again be to encrypt any HTML form source. A better solution would be to allocate memory dynamically, therefore not presetting the memory buffer to a certain size, or writing a function that checks the length of the input before passing the results to the server.
If the input exceeds the memory allocation, simply pass back a NULL value.
A simple, yet effective trick in deterring hackers is to configure your web server to hand out customised error 404 pages with a status of 200 when a resource is not found. Most genuine users will not even notice, and a hacker using software to scan for available resources will think they have stumbled across a gold mine.
When the hacker goes to check, they will find that they have been duped and hopefully see examining your site further as a waste of time. This could be seen as hacking hackers or the hacker becoming the hacked...
Netcat
You could take this one step further and use an old UNIX application called netcat to crash anyone who attempts to hack your site. Netcat makes and accepts TCP connections, but it can be used by a hacker for many things, including obtaining remote access to a shell, port-scanning and even hi-jacking services and bypassing firewalls.
It can also be used to monitor ports and flood suspicious requests, similar to a buffer over-run, by using it to pretend you are running a service that you are not and using the 'yes' command when someone tries to exploit that service.
Netcat is an extremely powerful application in itself and is usually part of any self-respecting hackers' tool-kit. Morally, you could look at this as hitting them back first.
Conclusion
I hope that I have drawn your attention to some of the more basic but often overlooked entry-points that a hacker may use to gain entry to your web applications, and highlighted the need for basic auditing of the security enforcement of your site.
This article is not intended to be a complete solution for defense against hacking, but more the starting point for your considerations. No site is completely hack-proof, but there are few sites that really need to be.
As a web developer ,your main security concern is first to assess how much security you will actually need. The more secure you need to be, the more your aims will move toward hiring the services of a professional security solution.
Cheers
