So lets start out with the basics, what is it? It all has to do with the URL bar and get variables. Let’s say that my site is “http://www.mysite.com/” and I created a script that grabs info out of my database based on it’s ID in the database. For example: “http://www.mysite.com/index.php?pageid=10″. My SQL statement will look like this: “SELECT * FROM pages WHERE ID=$_GET[id]“. Just like a regular SQL Injection, a hacker can submit malicious code using the get variable.

This is where we differ a little from a basic SQL Injection. In a basic SQL Injection, you simply type ' or 'x'='x into a form and it may or may not authenticate you. Your goal is to get it to toss an error, so that you know your code is not being parsed correctly.

Because we are retrieving info about a page with my example website script, not users, it makes it difficult to authenticate yourself with one line of code like a basic SQL Injection. There is one thing we can do, and that is to make the SELECT statement true or false. If my site is vulnerable, all we would need to type in the browser is: “http://www.mysite.com/index.php?pageid=10 and 1=1″. If it isn’t parsed correctly, my vulnerable code will now look like this: SELECT * FROM pages WHERE ID=10 and 1=1. That is a true statement so our page will display normally. Now we try a false statement: “http://www.mysite.com/index.php?pageid=10 and 1=2″ and our SQL query reads as: SELECT * FROM pages WHERE ID=10 and 1=2. This statement is false, so it will not grab ANY info from pages. With no info being grabbed from the database, our page will look significantly different. Maybe some pictures won’t be there, or text will be missing, or maybe the entire page will be blank. If that is the case, then you are in business.

So why is it called BLIND Sql Injection? Well rather than executing queries directly, like a regular SQL injection, and getting your info directly, you are now blind instead. You are using true/false statements to guess what the table names are, or manually hash them out using ascii codes and substrings. It can take hours to get access to a vulnerable site, but there are programs and scripts out there that will do all the work for you so you don’t even have to think about it.

If you want to know a little bit more about how this works, lets try it out on a vulnerable example: http://www.cblpi.org

Lets say I went to Ann Coulter’s bio page: http://www.cblpi.org/programs/bio.cfm?ID=15&type=Speaker

We notice that ID=15 and may be vulnerable. So we test it by typing: http://www.cblpi.org/programs/bio.cfm?ID=15 and 1=1&type=Speaker

Nothing changes! Let’s test it again by typing 1=2: http://www.cblpi.org/programs/bio.cfm?ID=15 and 1=2&type=Speaker

Now a blank page appears, so we know that the ID variable isn’t being parsed correctly.

Lets figure out what version of MySQL it is using BSI using @@version: http://www.cblpi.org/programs/bio.cfm?ID=15 and substring(@@version,1,1)=5&type=Speaker

If its version 5.xxxx it will show up as true! Does it? No. Then lets try 4: http://www.cblpi.org/programs/bio.cfm?ID=15 and substring(@@version,1,1)=4&type=Speaker

And know we know they are using version 4.xxxx of MySQL.

Lets try guessing a table name! http://www.cblpi.org/programs/bio.cfm?ID=15 and (select 1 from USERS limit 0,1)=1&type=Speaker

If table USERS exists, it will return 1 and the statement will be TRUE! Does it? No it doesn’t, but it does give us a nice error page saying it doesn’t exist, with the table name that we are currently selecting out of (PEOPLE).

So lets validate the code real quick. We know PEOPLE does exist, so http://www.cblpi.org/programs/bio.cfm?ID=15 and (select 1 from PEOPLE limit 0,1)=1&type=Speaker should be true.

And it is! The page displays normally.

You can bruteforce guess the table names, or there are many round about ways of detecting them letter by letter using substring and ascii functions. And once you figure out where the good information is stored, then you can break into those tables and grab it.

I’m not here to give you the exact methods on how to bruteforce it or use char codes, but just to give you the basics on what it is. Know that you know what it is, protect against it! How hard is it to check for a space? Add slashes? Check if it is an int? Guys common, these practices are standard when dealing with forms, why not make them standard when dealing with get variables. Recently (about 4-6 months ago) HyperVM was found to have a BSI vulnerability and within a couple of days, thousands and thousands of VPS servers were hacked and accounts deleted. It all could have been prevented with just one line of code.

<?php
$name=$_POST['name'];
$pass=$_POST['pass'];
$sql="SELECT * FROM Users WHERE Name='$name' AND Pass='$pass'";
?>

This would work perfectly, and would allow people to log in. It would also allow people to SQL inject it. What if they typed this in:

Well our SQL statement ends up looking like this:
SELECT * FROM Users WHERE Name='admin' AND Pass='admin' OR 'x'='x'
‘x’='x’ is a TRUE statement 100% of the time, so as long as ‘x’='x’, it will pull up all the info you needed, and suddenly you are logged in. This is probably the easiest SQL injection around, and does work on occasion. There are hundreds of SQL injections, and a poorly coded site will always be susceptible. Not only are people able to log into a site as an administrator, but they can display login info using UNION statements.
One other way good programmers tend to get lazy is through their “GET” variables. A lot of times programmers will pass variables in the URL bar: http://www.mysite.com/view.php?id=123. There is nothing wrong with this, in fact, everyone does it and will continue to do it because it is efficient and easy to do. The problem comes when people SQL inject that variable: view.php?id=123′ and ‘x’='y. This particular injection allows a hacker to test your site for susceptibility to injections in the URL bar. If you didn’t protect your variables, your SQL statement would look like this if it wasn’t protected: "SELECT * FROM Info WHERE Id='123' and 'x'='y'". If it wasn’t protected, the hacker would see a page with NO info on it, or an error because ‘x’ NEVER equals ‘y’ and is a FALSE statement. If they see a blank page or an error, they know they can continue their attack and eventually gain access to all of your information.

My goal is not to teach you how to hack, but rather how a simple PHP object exists and will help you avoid these types of attacks. That object is PDO. It comes standard with the latest releases of PHP and can be used to prevent SQL injections very simply. PDO is a database object, that allows you to connect to a variety of different databases, send queries, and display the results. It actually is a bit easier to code than actual mysql in PHP, but it is a complete 180 from what you have been taught using w3schools and tizag.com. I don’t really want to get into a tutorial of PDO either because there are quite a few on the internet that explain it much better than I can right now. I recommend checking out http://www.phpro.org/tutorials/Introduction-to-PHP-PDO.html to get a grip on the basics of how PDO works. The one thing that this tutorial does NOT explain is the “prepare” function. He only goes into it slightly, but doesn’t describe what it does exactly. Prepare() simply checks for all types of quotes and makes sure that no SQL injections can get through. Here is a quick example:

<?php
$mysql_host="localhost";
$mysql_user="root";
$mysql_pass='';
$mysql_database="epco";
try {
    $dbh = new PDO("mysql:host=$mysql_host;dbname=$mysql_database", $mysql_user, $mysql_pass);
    /*** create the statement ***/
    $stmt = $dbh->prepare("SELECT * FROM users WHERE user = :user AND pass = :pass");
    /*** bind the paramaters ***/
    $stmt->bindParam(':user', $_POST['user'], PDO::PARAM_STR);
    $stmt->bindParam(':pass', $_POST['pass'], PDO::PARAM_STR);
    /*** execute the prepared statement ***/
    $stmt->execute();
    /*** close the database connection ***/
    $dbh = null;    
}catch(PDOException $e){
    echo $e->getMessage();
}
?>

When we prepare our statement, we use a place-holder that will later assign a variable to. When that statement is executed, all our quotes are removed or slashed. $_POST['user']="admin' OR 1=1"; typically becomes $_POST['user']="admin\' OR 1=1"; and your database is protected from the attacks.

In conclusion, I am not advocating PDO and saying only to use that and nothing else. I use a database class that is much smaller and does what I need it to do. I have spoken with other programmers who have created their own class to add/strip slashes, rawurlencode/decode, and htmlspecialcharacters and connect to their databases. PDO was created as a “universal” database object that can do whatever you want it to do with several different databases. It is awesome and will go a long way to protect your site from SQL injections if used properly. The prepare statement is simple, but doesn’t protect against EVERY type of attack. Don’t be fooled into a false sense of security just because you are using a PHP object. XSS, javascript injections, and bruteforce, attacks are all still possible even if you use this class. Be careful in what you code, and fix any code when the holes are found by users or when you are hacked.

Step 1 – Create a new table!
Go to your MySQL database and create a table called “wp_counter” with 2 fields: Post_Id and Count. Both are Int with length 10. Here is the SQL code you can copy and paste to make it a bit shorter:
CREATE TABLE `wp_counter` (`Post_Id` INT( 10 ) NOT NULL , `Count` INT( 10 ) NOT NULL)

Step 2 – Editing post-template.php
This is the file that is used to display your posts (not the snippets on your front page, but full out posts). It is located in the “wp-includes” directory.
Open post-template.php for editing.
Search for a function called “the_content()“. It typically starts on line 165 should look like this:

165
166
167
168
169
170

function the_content($more_link_text = null, $stripteaser = 0, $more_file = '') {
	$content = get_the_content($more_link_text, $stripteaser, $more_file);
	$content = apply_filters('the_content', $content);
	$content = str_replace(']]>', ']]>', $content);
	echo $content;
}

So what we want to do is make it so that every time it shows the content, it will update the count and display it to the user. So we are going to change that function to look like this:

165
166
167
168
169
170
171
172

function the_content($more_link_text = null, $stripteaser = 0, $more_file = '') {
	$content = get_the_content($more_link_text, $stripteaser, $more_file);
	$content = apply_filters('the_content', $content);
	$content = str_replace(']]>', ']]>', $content);
	echo $content;
	update_count();
	echo"<small><i>Views: ".get_content_views()."</i></small>";
}

And immediately following that, we are going to add a couple functions:

173
174
175
176
177
178
179
180
181
182
183
184
185
186
187

function update_count(){
	global $wpdb, $id;
	if($wpdb->query($wpdb->prepare("SELECT * FROM wp_counter WHERE Post_Id='$id'"))==0)
		$wpdb->insert("wp_counter",array('Post_Id'=>$id,'Count'=>1),array('%d','%d'));
	else {
		$row=$wpdb->get_row($wpdb->prepare("SELECT * FROM wp_counter WHERE Post_Id='$id'"),ARRAY_A);
		$count=$row['Count']+1;
		$wpdb->update('wp_counter',array('Count'=>$count),array('Post_Id'=>$id),array('%d'),array('%d'));
	}
}
function content_views(){
	global $wpdb, $id;
	$row=$wpdb->get_row($wpdb->prepare("SELECT * FROM wp_counter WHERE Post_Id='$id'"),ARRAY_A);
	echo $row['Count'];
}

That’s it! So your finalized post-template.php will look like this:

function the_content($more_link_text = null, $stripteaser = 0, $more_file = '') {
	$content = get_the_content($more_link_text, $stripteaser, $more_file);
	$content = apply_filters('the_content', $content);
	$content = str_replace(']]>', ']]>', $content);
	echo $content;
	update_count();
	echo"<small><i>Views: ".get_content_views()."</i></small>";
}
function update_count(){
	global $wpdb, $id;
	if($wpdb->query($wpdb->prepare("SELECT * FROM wp_counter WHERE Post_Id='$id'"))==0)
		$wpdb->insert("wp_counter",array('Post_Id'=>$id,'Count'=>1),array('%d','%d'));
	else {
		$row=$wpdb->get_row($wpdb->prepare("SELECT * FROM wp_counter WHERE Post_Id='$id'"),ARRAY_A);
		$count=$row['Count']+1;
		$wpdb->update('wp_counter',array('Count'=>$count),array('Post_Id'=>$id),array('%d'),array('%d'));
	}
}
function content_views(){
	global $wpdb, $id;
	$row=$wpdb->get_row($wpdb->prepare("SELECT * FROM wp_counter WHERE Post_Id='$id'"),ARRAY_A);
	echo $row['Count'];
}
function get_content_views(){
	global $wpdb, $id;
	$row=$wpdb->get_row($wpdb->prepare("SELECT * FROM wp_counter WHERE Post_Id='$id'"),ARRAY_A);
	return $row['Count'];
}

Now every time someone visits the page, they will see how many other people have viewed that page!

It is posted in the Code Bin: Here