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. This article teaches to attack on those websites which have data base. So if your website doesn't use a database, you can relax a bit. From data base i mean to say if site asks for username and password which is stored in the database so as to keep records of all the users.
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 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 cyber laws.
What is SQL Injection?
SQL(Structured Query Language) and it is the language used by most website databases. SQL Injection is a technique used by hackers to gain access to confidential information or to change or delete the data that keeps your website running. Using this SQL Injection attack a hacker can also 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 you need to get rid of this kind if SQL injection and all other similar attacks.
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 = '" . $uname .
"' AND password = '" . $pword . "'";
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 simple example. In practice you need to do a bit more than this as there can be many variations on this attack.
No comments:
Post a Comment