HOW TO PROTECT UR SITE FROM SQLi

This is simple tutorial for beginners on
how to protect your site against SQL
Injection and this
tutorial will also help you check if your site
is vulnerable
to SQLi and how to make it resistant to SQLi.
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.
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.
How to resist against SQLi
Fixing this security loophole is not so
difficult. There are several ways to do it. If
you are using MySQL,, 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.