Here it is. Enjoy.
Article Options
Archives by Category
- Freebies (1)
- Personal (1)
- Web Development (1)
Archives by Year
- 2008 (3)
- Published in: Web Development
- with 6 comments
This article is intended for readers who have experience using PHP and MySQL. You should also have a general understanding of databases and programming (both procedural and object-oriented) as well as how to use PHP to execute a simple query to MySQL. I will not cover how to install PHP or MySQL, however at the end of the article are some links to help you get started with the installation process and for some further reading on the subject. I will be covering the basics of prepared statements in PHP and MySQLi and why you should consider using them in your own code as well as some technical explanation as to why you should use them.
Introduction
If you are like me and most other people, you probably have not taken the time to learn about web security when you first started writing server-side code. This is very dangerous as most people never even go back and try to make their code secure (or they simply forget). Writing their code in the same way that they originally learned how to can cause some serious vulnerabilities in the code, allowing hacking techniques such as SQL injections to be fairly easy. If you have no idea what MySQL injections or cross side scripting is, then you should do some research, for example just go to Google and type in "SQL Injections" and there will be plenty of reading for you. I also would recommend a book called, "How to Break Web Software", it is a fantastic book that one of my professors told one of my classes about. It can teach you a lot about security, it is highly recommended. I will have an article written shortly on SQL Injections, so check back soon! If you do know what some of these nasty hacking techniques are then you are probably wondering why you should want to use prepared statements. There are basically three reasons why you should seriously consider writing prepared statements to execute your queries.
- Prepared statements are more secure.
- Prepared statements have better performance.
- Prepared statements are more convenient to write.
Now that we know why prepared statements are better, let’s build an example so you can see for yourself. We’ll build a simple login example using prepared statements. First, I’ll show you the way most people would write it, then I’ll show you the way you could do it with a prepared statement which will be more secure, have better performance and be more convenient to write. Let’s get started!
The Well-Known Way
If you are reading this article, chances are you already know how to execute a simple MySQL query in PHP. For those of you who do not know how to do this, it would look similar to this:
/* Connect to the Database */
$dbLink = mysql_connect("localhost", "username", "password");
if (!dbLink) {
echo 'db link fail';
}
/* Select the database */
mysql_select_db("databaseName");
/* Query and get the results */
$query = "SELECT * FROM testUsers WHERE username='$user' AND
password='$pass'";
$result = mysql_query($query);
/* Loop through the results */
while($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
echo "Username: " . $row["username";
}
What is the problem with this code? Simple, someone could use a simple SQL injection to get around the password authentication. Why is this code angerous? If you know what an SQL injection does, it basically bypasses the password condition by commenting it out and uses an always true statement which allows access. Building strings on the fly like this should make you very nervous, but how do we make it more secure? Say hello to prepared statements.
Prepared Statements
What is so great about prepared statements and why are they more secure? The simple answer is because prepared statements can help increase security by separating the SQL logic from the data being supplied. In the previous example we saw how the data is basically built into the SQL logic by building the query as a string on the fly. Let’s take a look at what a prepared statement can look like.
/* Create a new mysqli object with database connection parameters */
$mysqli = new mysql('localhost', 'username', 'password', 'db');
if(mysqli_connect_errno()) {
echo "Connection Failed: " . mysqli_connect_errno();
exit();
}
/* Create a prepared statement */
if($stmt = $mysqli -> prepare("SELECT priv FROM testUsers WHERE username=?
AND password=?")) {
/* Bind parameters
s - string, b - boolean, i - int, etc */
$stmt -> bind_param("ss", $user, $pass);
/* Execute it */
$stmt -> execute();
/* Bind results */
$stmt -> bind_results($result);
/* Fetch the value */
$stmt -> fetch();
echo $user . "'s level of priviledges is " . $result;
/* Close statement */
$stmt -> close();
}
/* Close connection */
$mysqli -> close();
Doesn’t look too bad, right? In short, the above code basically creates a new mysqli object and connects to the database. We then create a prepared statement and bind the incoming parameters to that statement, execute it and get the result. We then close the statement and connect and we’re done! Pretty easy!
Let’s take a look at where the security happens in these few lines:
if($stmt = $mysqli -> prepare("SELECT priv FROM testUsers WHERE username=?
AND password=?")) {
$stmt -> bind_param("ss", $user, $pass);
Instead of grabbing and building the query string using things like $_GET['username'], we have ?'s instead. These ?'s separate the SQL logic from the data. The ?'s are place holders until the next line where we bind our parameters to be the username and password. The rest of the code is pretty much just calling methods which you can read about by following some of the links at the end of the article.
Summary
In this article we have covered why and how you should use prepared statements. You should now have a solid understanding of the benefits associated with using prepared statements as well as how to use prepared statements. If you did not know before, after reading this article you should have a basic understanding of the object-oriented interface to MySQLi. I hope this was helpful to you and if you have any questions feel free to post some comments below!
Further Reading
- MySQLi Manual The MySQLi manual that is on PHP.net.
- PHP.net Excellent PHP resource.
- Prepared Statements Pretty awesome article over at Database Journal on prepared statements.
- Installing PHP and MySQLi Good installation tutorial.
Subscribe to the Notebook RSS Feed
Print this Article
.PDF of the Article
6 people left comments
Chuck on May 28, 2008 at 11:16 AM wrote:
I'm a total rookie so took me a few minutes to figure this out:
$stmt -> bind_results($result);
above should be:
$stmt -> bind_result($result);
"bind_result", not "bind_results"
:)
Matt Bango on April 29, 2008 at 4:36 PM wrote:
@Ryan - Thank you for the great, in-depth post. There is a lot of great information in there that I didn't know/think about and will be very valuable to the readers. Thanks for sharing your knowledge on the subject!
@Rob - Thanks for posting. If anyone is interested, there is a great SQL injection cheat sheet here: http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
Ryan S. on April 28, 2008 at 10:49 AM wrote:
One thing to take note of: prepared statements are _not_ guaranteed better performance. The reason for this is that, in a prepared statement, there are actually at least two calls performed to the server. The first is the prepare(), when the statement is compiled; the second is the actual execution after all parameters are bound.
In many cases, a single SELECT (especially in an unbuffered result set) can run much slower than if you queried directly. The alternative, in this case, would be to use mysqli::real_escape_string() to properly escape your external GPC variables without the extra call to the MySQL server. The speed benefits of prepared statements really only kick in when you're executing the same query within a script multiple times (think: saving the line items of a shopping cart to an order invoice, where you'll reuse the same INSERT, rebound for each line item).
The advantage of the real_escape_string() approach is that the mysqli driver can properly escape whichever character set you're working in, without adding extra server overhead. For most sites out there, this is the recommended solution. The only exceptions would be those who regularly switch the default MySQL character set through SQL statements, those who use custom session handlers to save to and load from MySQL, and those who employ the same CRUD query multiple times in the same script.
Rob S on April 27, 2008 at 12:03 PM wrote:
You forgot ' OR 1 = 1 --. Great post. Dan would be proud.
Matt Bango on April 14, 2008 at 2:28 PM wrote:
I'm assuming you're talking about the SQL Injections? If you look back at the code in the "Well-Known Way" and focus your attention to the query line, you will see that this query is being built on the fly as a string. Now pay attention to this part:
WHERE username='$user'
A visitor/hacker could easily do something like this in the username input:
' OR true --
The first ' closes the string, then the OR true part is always true and finally the -- comments the rest of the query out, ultimately resulting in running an always true query which will all the visitor/hacker to gain access to your site. So when I say comment out the server side code, I'm referring to commenting out the rest of the query by using -- or #. I hope this helps, if you have any other questions feel free to post!
k on April 13, 2008 at 12:12 AM wrote:
I'm not an expert on the subject, but how is it possible to comment a server side code? from a visitor/hacker perspective.
Share your thoughts