What is SQL Injection?
Posted: Wed Nov 13, 2013 11:42 pmSQL injection (or a SQL injection attack) occurs when a user provides SQL code as user input for a Web page, and the SQL code is then executed in the database.
see one example below:
SELECT * FROM Users WHERE Username='$_POST['Username’]' AND Password='$_POST['Password’]'
which is designed to show all records from the table "Users" for a username and password supplied by a user. Using a Web interface, when prompted for his username and password, a malicious user might enter:
1' or '1' = '1
1' or '1' = '1
resulting in the query:
SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'
The hacker has effectively injected a whole OR condition into the authentication process. Worse, the condition '1' = '1' is always true, so this SQL query will always result in the authentication process being bypassed.
There are several PHP functions that can be used to avoid this vulnerability. See one example :
We can prevent SQL injection is by using parameterized queries. This means defining the SQL code that is to be executed with placeholders for parameter values, programmatically adding the parameter values, then executing the query. Doing this allows the server to create an execution plan for the query, which prevents any "injected" SQL from being executed.
Let’s use the same example, but I will define the SQL query with parameter placeholders:
$sql = "SELECT * FROM Users WHERE Username = ? and Password = ?";
Now, define an array that holds the parameter values:
$params = array($_POST['Username’], $_POST['Password’]);
When execute the query, we can pass the $params array as an argument:
$stmt = sqlsrv_query($conn, $sql, $params);
When sqlsrv_query is called, an execution plan is created on the server before the query is executed. The plan only allows our original query to be executed. Parameter values (even if they are injected SQL) won’t be executed because they are not part of the plan. So, if we submit a password like above example ('or 1=1--), it will be treated as user input, not SQL code. In other words, the query will look for a user with this password instead of executing unexpected SQL code.
Also I would like to share one Infographic regarding Injection Attack.
see more @
see one example below:
SELECT * FROM Users WHERE Username='$_POST['Username’]' AND Password='$_POST['Password’]'
which is designed to show all records from the table "Users" for a username and password supplied by a user. Using a Web interface, when prompted for his username and password, a malicious user might enter:
1' or '1' = '1
1' or '1' = '1
resulting in the query:
SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'
The hacker has effectively injected a whole OR condition into the authentication process. Worse, the condition '1' = '1' is always true, so this SQL query will always result in the authentication process being bypassed.
There are several PHP functions that can be used to avoid this vulnerability. See one example :
We can prevent SQL injection is by using parameterized queries. This means defining the SQL code that is to be executed with placeholders for parameter values, programmatically adding the parameter values, then executing the query. Doing this allows the server to create an execution plan for the query, which prevents any "injected" SQL from being executed.
Let’s use the same example, but I will define the SQL query with parameter placeholders:
$sql = "SELECT * FROM Users WHERE Username = ? and Password = ?";
Now, define an array that holds the parameter values:
$params = array($_POST['Username’], $_POST['Password’]);
When execute the query, we can pass the $params array as an argument:
$stmt = sqlsrv_query($conn, $sql, $params);
When sqlsrv_query is called, an execution plan is created on the server before the query is executed. The plan only allows our original query to be executed. Parameter values (even if they are injected SQL) won’t be executed because they are not part of the plan. So, if we submit a password like above example ('or 1=1--), it will be treated as user input, not SQL code. In other words, the query will look for a user with this password instead of executing unexpected SQL code.
Also I would like to share one Infographic regarding Injection Attack.
see more @
