Web vulnerabilities - part 2 - SQLI + preventing advice 11-19-2012, 10:28 PM
#1
I know the subject is overdosed but i am writing about all web vulnerabilities into "web vulnerabilities" mini-series, so here's the part about SQLI!
SQL injection vulnerability is still quite common these days even though it’s been present for over ten years. SQL injection vulnerability happens when the application isn’t checking the input values for special characters and encapsulating them, and uses the inputted value in the SQL query. An example of such an application can be seen below:
We can see that we’re checking whether the parameters username and password exist and have a correspondent value. If they have, we’re reading the values into the $user and $pass variables. Afterwards we’re connecting to the SQL database on localhost:3306 with a username admin and password admin and selecting the database db. Then we’re constructing an SQL query sentence in which we’re including the exact values from the username and password inputted values without checking it for special characters.
But we should do that, because the above code is vulnerable to SQL injections, because we’re not encapsulating the username and password inputted values. Imagine that we enter a value ‘ OR 1=1–’ into both the username and password field. After that the constructed SQL query will be as follows:
This effectively selects all users from the table users because of the OR directive we’ve passed to the vulnerable application. The above SQL query is always evaluated to true and we don’t need to enter the right username and password, which would log us into the application. Instead we can enter special input values to break the logic behind the application and login nevertheless.
Prevention
here’s some quick tips (i will come back with a complex tutorial about sqli prevention)
addslashes http://us2.php.net/manual/en/function.addslashes.php
also:
mysql_escape_string http://us2.php.net/manual/en/functio…ape-string.php
be aware if magic quotes is turned on
http://us2.php.net/manual/en/functio…quotes-gpc.php
SQL injection vulnerability is still quite common these days even though it’s been present for over ten years. SQL injection vulnerability happens when the application isn’t checking the input values for special characters and encapsulating them, and uses the inputted value in the SQL query. An example of such an application can be seen below:
PHP Code:
<html>
<body>
<?php
$show = 1;
if(!empty($_GET['username']) and !empty($_GET['password'])) {
$user = $_GET['username'];
$pass = $_GET['password'];
mysql_connect("localhost", "admin", "admin");
mysql_select_db("db");
$result = mysql_query("SELECT * FROM users WHERE username='".$user."' \
AND password='".$pass."';");
$row = mysql_fetch_row($result);
if($row) {
echo "Welcome user: ".$user;
$show = 0;
}
}
?>
<?php if($show) { ?>
<form action="#">
Username: <input type="text" name="username" /><br />
Password : <input type="password" name="password" /><br />
</form>
</body>
</html>
<?php } ?>We can see that we’re checking whether the parameters username and password exist and have a correspondent value. If they have, we’re reading the values into the $user and $pass variables. Afterwards we’re connecting to the SQL database on localhost:3306 with a username admin and password admin and selecting the database db. Then we’re constructing an SQL query sentence in which we’re including the exact values from the username and password inputted values without checking it for special characters.
But we should do that, because the above code is vulnerable to SQL injections, because we’re not encapsulating the username and password inputted values. Imagine that we enter a value ‘ OR 1=1–’ into both the username and password field. After that the constructed SQL query will be as follows:
PHP Code:
SELECT * FROM users WHERE username='' OR 1=1--'' AND password='' OR 1=1--''
This effectively selects all users from the table users because of the OR directive we’ve passed to the vulnerable application. The above SQL query is always evaluated to true and we don’t need to enter the right username and password, which would log us into the application. Instead we can enter special input values to break the logic behind the application and login nevertheless.
Prevention
here’s some quick tips (i will come back with a complex tutorial about sqli prevention)
addslashes http://us2.php.net/manual/en/function.addslashes.php
also:
mysql_escape_string http://us2.php.net/manual/en/functio…ape-string.php
be aware if magic quotes is turned on
http://us2.php.net/manual/en/functio…quotes-gpc.php



![[+]](https://sinister.li/images/modern/collapse_collapsed.png)