hacking website easely

I want to worry you.

I want to show you just one way that hackers can get in to your website and mess it up, using a technique called SQL Injection. And then I'll show you how to fix it. This article touches on some technical topics, but I'll try to keep things as simple as possible. There are a few very short code examples written in PHP and SQL. These are for the techies, but you don't have to fully understand the examples to be able to follow what is going on. Please also note that the examples used are extremely simple, and Real Hackers™ will use many variations on the examples listed.

If your website doesn't use a database, you can relax a bit; this article doesn't apply to your site — although you might find it interesting anyway. If your site does use a database, and has an administrator login who has rights to update the site, or indeed any forms which can be used to submit content to the site — even a comment form — read on.

Warning

This article will show you how you can hack in to vulnerable websites, and to check your own website for one specific vulnerability. It's OK to play around with this on your own site (but be careful!) but do not be tempted to try it out on a site you do not own. If the site is properly managed, an attempt to log in using this or similar methods will be detected and you might find yourself facing charges under the Computer Misuse Act. Penalties under this act are severe, including heavy fines or even imprisonment.

What is SQL Injection?

SQL stands for Structured Query Language, and it is the language used by most website databases. SQL Injection is a technique used by hackers to add their own SQL to your site's SQL to gain access to confidential information or to change or delete the data that keeps your website running. I'm going to talk about just one form of SQL Injection attack that allows a hacker to log in as an administrator - even if he doesn't know the password.

Is your site vulnerable?

If your website has a login form for an administrator to log in, go to your site now, in the username field type the administrator user name.

In the password field, type or paste this:

x' or 'a' = 'a

If the website didn't let you log in using this string you can relax a bit; this article probably doesn't apply to you. However you might like to try this alternative:

x' or 1=1--

Or you could try pasting either or both of the above strings into both the login and password field. Or if you are familiar with SQL you could try a few other variations. A hacker who really wants to get access to your site will try many variations before he gives up.

If you were able to log in using any of these methods then get your web tech to read this article, and to read up all the other methods of SQL Injection. The hackers and "skript kiddies" know all this stuff; your web techs need to know it too.

The technical stuff

If you were able to log in, then the code which generates the SQL for the login looks something like this:

$sql =
"SELECT * FROM users
"WHERE username = '" . $username .
"' AND password = '" . $password . "'";

When you log in normally, let's say using userid admin and password secret, what happens is the admin is put in place of

$username

and secret is put in place of

$password

. The SQL that is generated then looks like this:

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'secret'

But when you enter

x' or 'a' = 'a

as the password, the SQL which is generated looks like this:

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'x' or 'a' = 'a'

Notice that the string:

x' or 'a' = 'a

has injected an extra phrase into the WHERE clause:

or 'a' = 'a'

. This means that the WHERE is always true, and so this query will return a row contain the user's details.

If there is only a single user defined in the database, then that user's details will always be returned and the system will allow you to log in. If you have multiple users, then one of those users will be returned at random. If you are lucky, it will be a user without administration rights (although it might be a user who has paid to access the site). Do you feel lucky?

How to defend against this type of attack

Fixing this security hole isn't difficult. There are several ways to do it. If you are using MySQL, for example, the simplest method is to escape the username and password, using the mysql_escape_string() or mysql_real_escape_string() functions, e.g.:

$userid = mysql_real_escape_string($userid);
$password = mysql_real_escape_string($password);
$sql =
"SELECT * FROM users
"WHERE username = '" . $username .
"' AND password = '" . $password . "'";

Now when the SQL is built, it will come out as:

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'x\' or \'a\' = \'a'

Those backslashes ( \ ) make the database treat the quote as a normal character rather than as a delimiter, so the database no longer interprets the SQL as having an OR in the WHERE clause.

This is just a simplistic example. In practice you will do a bit more than this as there are many variations on this attack. For example, you might structure the SQL differently, fetch the user using the user name only and then check manually that the password matches or make sure you always use bind variables (the best defence against SQL injection and strongly recommended!). And you should always escape all incoming data using the appropriate functions from whatever language your website is written in - not just data that is being used for login.

There's more

This has just been a brief overview. There are many more hacking techniques than SQL Injection; there are many more things that can be done just using SQL Injection. It is possible to directly change data, get access to confidential information, even delete your whole database — irrespective of whether the hacker can actually log in — if your website isn't set up correctly.

If you are hungry for more, this detailed article from SecuriTeam explains other techiques hackers might use, as well as some of the methods hackers use to work out the structure of your database, the userid of the admin user, gain access to your system's configuration, etc.

How They Hack Your Website: Overview of Common Techniques

How They Hack Your Website: Overview of Common Techniques

We hear the same terms bandied about whenever a popular site gets hacked. You know… SQL Injection, cross site scripting, that kind of thing. But what do these things mean? Is hacking really as inaccessible as many of us imagine — a nefarious, impossibly technical twilight world forever beyond our ken?

Not really.

When you consider that you can go to Google right now and enter a search string which will return you thousands of usernames and passwords to websites, you realize that this dark science is really no mystery at all. You'll react similarly when you see just how simple a concept SQL Injection is, and how it can be automated with simple tools. Read on, to learn the basics of how sites and web content management systems are most often hacked, and what you can do to reduce the risk of it happening to you.

SQL Injection

SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application.

When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out.

The Simple SQL Injection Hack

In its simplest form, this is how the SQL Injection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon.

Suppose we enter the following string in a Username field:

' OR 1=1

The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:

SELECT * FROM users WHERE username = ?USRTEXT '
AND password = ?PASSTEXT?

…where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form.

So entering `OR 1=1 — as your username, could result in the following actually being run:

SELECT * FROM users WHERE username = ?' OR 1=1 — 'AND password = '?

Two things you need to know about this:
['] closes the [username] text field.

'' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes:

SELECT * FROM users WHERE username = '' OR 1=1

1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc.

Let's hope you got the gist of that, and move briskly on.

Brilliant! I'm gonna go hack me a Bank!
Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank, evidently.

But the process does serve to illustrate just what SQL Injection is all about — injecting code to manipulate a routine via a form, or indeed via the URL. In terms of login bypass via Injection, the hoary old ' OR 1=1 is just one option. If a hacker thinks a site is vulnerable, there are cheat-sheets all over the web for login strings which can gain access to weak systems. Here are a couple more common strings which are used to dupe SQL validation routines:

username field examples:

• admin'—
• ') or ('a'='a
• ”) or (“a”=”a
• hi” or “a”=”a

… and so on.

Backdoor Injection- Modules, Forums, Search etc.
Hacking web forms is by no means limited exclusively to login screens. A humble search form, for instance, is necessarily tied to a database, and can potentially be used to amend database details. Using SQL commands in search forms can potentially do some extremely powerful things, like calling up usernames and passwords, searching the database field set and field names, and amending same. Do people really get hacked through their search forms? You better believe it. And through forums, and anywhere else a user can input text into a field which interacts with the database. If security is low enough, the hacker can probe the database to get names of fields, then use commands like INSERT INTO, UNION, and so forth to get user information, change product prices, change account settings/balances, and just about anything else… depending on the security measures in place, database architecture and so on.

So you can have security locked down at the login, but poor security on other forms can still be exploited. Unfortunately this is a real worry regarding 3rd party modules for Web CMS products which incorporate forms, and for CMS products these 3rd party modules are often the weakest links which allows hackers access to your database.

Automated Injection
There are tools to automate the process of SQL Injection into login and other fields. One hacker process, using a specific tool, will be to seek out a number of weak targets using Google (searching for login.asp, for instance), then insert a range of possible injection strings (like those listed above, culled from innumerable Injection cheat-sheets on the Web), add a list of proxies to cover his movements, and go play XBox while the program automates the whole injection process.

Remote Injection
This involves uploading malicious files to inject SQL and exploit other vulnerabilities. It's a topic which was deemed beyond the scope of this report, but you can view this PDF if you'd like to learn more.

SQL Injection in the Browser Address Bar
Injections can also be performed via the browser address bar. I don't mean to have a pop at Microsoft, but when it comes to such vulnerabilities, HTTP GET requests with URLs of the following form are most often held to be vulnerable:

http://somesite.com/index.asp?id=10

Try adding an SQL command to the end of a URL string like this, just for kicks:
http://somesite.com/index.asp?id=10 AND id=11

See if both articles come up. Don't shoot your webmaster just yet if it's your own site and you get two articles popping up: this is real low-level access to the database. But some such sites will be vulnerable. Try adding some other simple SQL commands to the end of URLs from your own site, to see what happens.