By Nilesh Sah, Atul Goel and Jeeri Deka
SQL Injection is a relatively easy technique to “hack” into a website. It gained popularity in 2008, when most websites didn’t employ proper means to avoid this kind of access. Now, this is the exploitation of the vulnerability in the application.

Here’s a basic example of SQL Injection : Suppose our beloved VOLSBB is based on SQL with that vulnerability still existing and it asks for any id or password.
Picture
Prontonetworks @VIT
You enter the details and it gives you access. Is it actually that simple? Let’s have a look at the back-end(the pages of programming  code that lies behind). Here’s one instant from lengthy code of some stupid random program.
We don’t care about the multitudes of this geeky stuff, but one line actually seems interesting - the line which checks for the authentication of userID and password which is:
Here $USER_ID is a variable. And suppose we enter “Swenews” in the login id, the system reads it as:
An important point to note is that Single line comments in SQL begin with “- -“ and each command is terminated with a semi-colon,  and when we enter some strange userID such as this  anything' OR 'x'='x, the resulting SQL will be :
Now whatever the case may be, 'x'='x' clause is guaranteed to be true no matter what the first clause is and the “OR” operator returns us the final result as a true value.

Voila! Doing so, we were greeted with:
My best guess is that it's the first record returned by the query, effectively an entry taken at random.

This is the easiest way for bypassing the SQL loopholes. But now, almost all the websites have incorporated escape commands which trims all specials characters in the username and password fields. Now, it has become more challenging, but isn’t impossible altogether.

P.S.: We only hope our VOLSBB was this easy.