What does "x = ?" mean in condition of an SQL query? [duplicate] - php

This question already has answers here:
What is the question mark's significance in MySQL at "WHERE column = ?"?
(4 answers)
How can I prevent SQL injection in PHP?
(27 answers)
Closed 8 years ago.
I need help to figure out what this sentence mean:
SELECT id, username, password FROM users WHERE email = ?LIMIT 1
I know what LIMIT 1 means but what the '= ?' is for ?

It's a prepared statement.
A prepared statement or a parameterized statement is used to execute the same statement repeatedly with high efficiency.
The prepared statement execution consists of two stages: prepare and execute. At the prepare stage a statement template is sent to the database server. The server performs a syntax check and initializes server internal resources for later use.
Prepare is followed by execute. During execute the client binds parameter values and sends them to the server. The server creates a statement from the statement template and the bound values to execute it using the previously created internal resources.
A prepared statement can be executed repeatedly. Upon every execution the current value of the bound variable is evaluated and sent to the server. The statement is not parsed again. The statement template is not transferred to the server again.
Every prepared statement occupies server resources. Statements should be closed explicitly immediately after use. If not done explicitly, the statement will be closed when the statement handle is freed by PHP.
Using a prepared statement is not always the most efficient way of executing a statement. A prepared statement executed only once causes more client-server round-trips than a non-prepared statement.
This example performs an INSERT query by substituting a name and a value for the positional ? placeholders.
<?php
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (?, ?)");
$stmt->bindParam(1, $name);
$stmt->bindParam(2, $value);
// insert one row
$name = 'one';
$value = 1;
$stmt->execute();
I recommend reading that entire tutorial. You should also check out PDO.

Your query:
SELECT id, username, password FROM users WHERE email = ? LIMIT 1
? sign means placeholder.
I suppose, you use pdo. When you will execute your query
$email = // get some email
$stmt = $dbh->prepare("SELECT id, username, password FROM users WHERE email = ? LIMIT 1");
$stmt->bindParam(1, $email);
value of variable $email will be placed insetead of ? like:
SELECT id, username, password FROM users WHERE email = 'bob#gmail.com' LIMIT 1
You can find more information about it here

Related

prepared Query strings [duplicate]

This question already has answers here:
How to echo a MySQLi prepared statement?
(6 answers)
Closed 5 years ago.
Is there any function that will return the prepared query string after processing all the parameters. like
$stmt = $conn->prepare("SELECT full_name FROM user_info where user_id = ?");
$stmt->bind_param("s", $user_id);
Can I see the final query string that will execute?
If the driver is capable of using prepared statements, if it doesn't require emulation, then the final query executed is the prepared statement.
If you want to find out what was executed, you need to turn on the general query log on your server. That can be very, very noisy and fill up your disk quickly on a busy server.

Restricting php pdo execute() to running just the first sql statement [duplicate]

This question already has answers here:
How can I prevent SQL injection in PHP?
(27 answers)
Closed 8 years ago.
Is there a way to restrict php pdo execute() to run just the first sql statement?
For instance running
SELECT * FROM customer;DROP TABLE invoice
will return all customers but it will also delete the invoice table.
I have a situation where I need a whole SQL statement from a user but it must be a SELECT and nothing additional.
My example is just one of many that could be maliciously entered. It might include additional DROP, UPDATE, DELETE statements etc.
A prepared statement will simply replace ?s with values. It will not stop dangerous SQL statemets being passed to it.
This would not be a problem if there was a way to restrict php pdo execute() to run just the first sql statement?
IF your trying to prevent SQL injection, prepare statements can handle it.
you can use something like this to prevent SQL injection
$stmt = $db->prepare("SELECT * FROM table WHERE id=? AND name=?");
$stmt->bindValue(1, $id, PDO::PARAM_INT);
$stmt->bindValue(2, $name, PDO::PARAM_STR);
$stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);

What does bind_param accomplish?

I'm learning about avoiding SQL injections and I'm a bit confused.
When using bind_param, I don't understand the purpose. On the manual page, I found this example:
$stmt = mysqli_prepare($link, "INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)");
mysqli_stmt_bind_param($stmt, 'sssd', $code, $language, $official, $percent);
$code = 'DEU';
$language = 'Bavarian';
$official = "F";
$percent = 11.2;
Now, assuming those 4 variables were user-inputted, I don't understand how this prevents SQL injections. By my understanding, they can still input whatever they want in there.
I also can't find an explanation for the 'sssd' in there. What does it do? Is that what makes it secure-er?
Final question: I read on another question that mysqli_real_escape_string is deprecated, but it doesn't say that in the manual. How is it deprecated? Can it not escape special characters anymore for some reason?
Note: This question explained what bind_param does, but I still don't understand why it is any safer or more protected.
Bind_param explanation
Now, assuming those 4 variables were user-inputted, I don't understand
how this prevents SQL injections. By my understanding, they can still
input whatever they want in there.
The main principle there is using prepared statement which is designed for sending safe query to db server, this can be done by escaping user input which is not part of the real query, and also checking the query without any (where clause) to check the validity of the query before using any parameters.
From this question: PDO sends raw query to MySQL while Mysqli sends prepared query, both produce the same result
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username =?")) {
$stmt->bind_param("i", $user);
$user = "''1''";
server logs:
130802 23:39:39 175 Connect ****#localhost on testdb
175 Prepare SELECT * FROM users WHERE username =?
175 Execute SELECT * FROM users WHERE username =0
175 Quit
By Using prepared statement, db server will check the query without any parameter, at this stage, errors can be detected before binding any parameter, then, if the query was valid, parameters also will be send to the server for finalizing the query.
From PHP Manual http://php.net/manual/en/mysqli.quickstart.prepared-statements.php:
Escaping and SQL injection
Bound variables will be escaped automatically by the server. The
server inserts their escaped values at the appropriate places into the
statement template before execution. A hint must be provided to the
server for the type of bound variable, to create an appropriate
conversion. See the mysqli_stmt_bind_param() function for more
information.
..
I also can't find an explanation for the 'sssd' in there. What does it
do? Is that what makes it secure-er?
The answer is here: http://php.net/manual/en/mysqli-stmt.bind-param.php
i
corresponding variable has type integer
d
corresponding variable has type double
s
corresponding variable has type string
b
corresponding variable is a blob and will be sent in packets
Final question: I read on another question that
mysqli_real_escape_string is deprecated, but it doesn't say that in
the manual. How is it deprecated? Can it not escape special characters
anymore for some reason?
Can you give a reference? I think you misunderstood with (mysql_real_escape_string())
By using prepared statements you are separating SQL queries from user entered data. Instead of input data, you put placeholders ('?' char) in your SQL query. Then you send the query to the DBMS server (e.g.: MySQL) by means of the "mysqli::prepare" method. So the server checks that everything is ok and, if so, it waits for input data. By now it already knows your query. Just it has to wait for input data to bind to the query.
At this point, "bind_param" comes into action, binding placeholders to user entered data.
Notice that bind_param only binds data to placeholders leaving unchanged the query.
So there is not way to change the original SQL query, because it has already sent to the server by means of the prepare method and because you are sending SQL queries and input data separately so user entered data can't interfere with queries.
ANYWAY...
The actual purpose to use a prepared statement in SQL is to cut the cost of processing queries, NOT to separate data from query. That's how it's being used now, not how it was designed to be used in the first place.
'sssd' stands for "string", "string", "string" and "double".
In fact: $code is a string, $language is a string, $official is a string and $percent is a double type.
mysqli_real_escape_string is not deprecated but mysql_real_escape_string is deprecated
(the first one is mysqlI, where I stands for "improved").

PHP MySQLI Prevent SQL Injection [duplicate]

This question already has answers here:
How can I prevent SQL injection in PHP?
(27 answers)
Closed 9 years ago.
I've build a website that will be going live soon and just have a couple questions about preventing SQL injection, I understand how to use mysqli_real_escape_string but I'm just wondering if I have to use that on all variables that I'm getting for my SQL statement and do I have to use it when I'm doing select statements also or just on insert update and delete? Also what other security would you recommend me implementing before I put the site live, thanks in advance for any help!
Any query can be injected whether it's read or write, persistent or transient. Injections can be performed by ending one query and running a separate one (possible with mysqli), which renders the intended query irrelevant.
Any input to a query from an external source whether it is from users or even internal should be considered an argument to the query, and a parameter in the context of the query. Any parameter in a query needs to be parameterized. This leads to a properly parameterized query that you can create a prepared statement from and execute with arguments. For example:
SELECT col1 FROM t1 WHERE col2 = ?
? is a placeholder for a parameter. Using mysqli, you can create a prepared statement using prepare, bind a variable (argument) to a parameter using bind_param, and run the query with execute. You don't have to sanitize the argument at all (in fact it's detrimental to do so). mysqli does that for you. The full process would be:
$stmt = $mysqli->prepare("SELECT col1 FROM t1 WHERE col2 = ?");
$stmt->bind_param("s", $col2_arg);
$stmt->execute();
There is also an important distinction between parameterized query and prepared statement. This statement, while prepared, is not parameterized and is thus vulnerable to injection:
$stmt = $mysqli->prepare("INSERT INTO t1 VALUES ($_POST[user_input])");
To summarize:
All Queries should be properly parameterized (unless they have no parameters)
All arguments to a query should be treated as hostile as possible no matter their source

Prepared statement vs classic insert query [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Php PDO::bindParam data types.. how does it work?
Could someone explain - why is prepared statement more secure:
$stmt = $conn->prepare("INSERT INTO users (user, pass, salt)
VALUES (:user, :pass, :salt");
$stmt->bindParam(":user", $user);
$stmt->bindParam(":pass", $pass);
$stmt->bindParam(":salt", $salt);
$stmt->execute();
Insert query is firstly prepared with placeholders, then values is placed instead placeholders, but - where is that famous secure point ?
The values are not placed into the placeholders (depending on the backend, some do emulation but lets not talk about them, as that's not prepared statements). The issue with traditional SQL is that the commands and data are mixed. Prepared statements get around that issue by intentionally keeping them separate at all times. Prepared statements aren't just a fancy way to automatically do mysqli_real_escape_string.

Categories