James Wilson --blog

I brought out Acunetix to test the script that I'm writing. It's a pretty noisy web vulnerability scanner that tests for XSS, SQL Injection, server vulnerabilities, and other things that just shouldn't be around. I'm not going to reveal too much about my script, but it consists of a user system, private messaging, posting with revision history, threaded replying, completely dependent on mod_rewrite, and some other things, all coded from the ground up with security in mind while doing it. So I was pretty surprised when Acunetix showed 352 'alerts'.

First off, SQL Injection. It showed 48 cases of successful SQL Injections. Crap! Luckily, all 48 injections were for one page, the deleting of private messages. These consisted of setting POST variable 5 or 7 or 1 to ' or %27 or %2527 or " or '" and so on, and the response it would get would be:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1

Once this gets out of development, I would change this to email me instead of just showing it, but it was still giving a valid SQL problem. This was kinda confusing, since it only cares if POST variable 5 is set and equal to "on". If it's anything else, it just ignores it.

First, I'll explain how my message deletion system works. The inbox consists of a table of message titles, the sender, time sent, and a little checkbox to delete the message. The checkbox name is equal to the message id. Then there is a hidden input that lists all the message ids seperated by commas, like

<input type="hidden" name="messages" value="10,7,5,1" />

So, once the form is submitted, it explodes $_POST['messages'] and runs through each one to check if the POST variable matching the message id is set and equal to "on". (Note: I could've just put the $_POST array in a foreach loop and done it from there, like foreach($_POST as $key => $value) { /* check it */ }, but for some reason I didn't.

Here's the code to it. There is also a check to make sure that the POST variable hash is set to what it should be. This is used to protect from someone putting a form to delete a user's messages in an iframe or something.

if(isset($_POST['delete']) AND $_POST['delete'] == "Delete Messages") {
	if(isset($_POST['messages'])) {
		$messages = explode(",",$_POST['messages']);
		$where = ($_POST['type'] == "sent") ? " WHERE `sender_id` = '$logged_user_id' AND ( " : " WHERE `receiver_id` = '$logged_user_id'  AND (  ";
		$done = false;
		foreach($messages as $message) {
			if(is_numeric($message) AND isset($_POST[$message]) AND $_POST[$message] == "on") {
				if(!$done) {
					$where .= " `msg_id` = '$message' ";
					$done = true;
				}
				else {
					$where .= " OR `msg_id` = '$message' ";
				}
			}
		}
		$where .= " ) ";
 
		$query = "UPDATE `privmsgs` SET ".(($_POST['type'] == "sent") ? "`senderbox` = 'Deleted'":"`receiverbox` = 'Deleted'")." , `timedeleted` = ".time()." $where";
 
		mysql_query($query) or die(mysql_error());
 
 
	}
}

If you notice, the POST variable 5 doesn't get anywhere near the query. It's checked to see if it's set and equal to "on". The variable from $_POST['messages'] is the one put in the query, and that's only if it's also numeric.

So, I launched the attack in it's HTTP Editor and set the page to just echo the query, and it printed:

UPDATE `privmsgs` SET `receiverbox` = 'Deleted' , `timedeleted` = 1175118688 WHERE `receiver_id` = '1' AND ( )

Aha! No messages where equal to "on", but the query still fired. Simple fix. Just enclose the query in the if statement if($done), and that bug is squashed. There was no possibility of SQL injection though. So even though it was inaccurate, it did help me find a bug.

Next, Blind SQL/XPath Injection. It states that the variables post and posthash are vulnerable. Uh, no? These are never placed into the database, just to make sure the person is posting instead of previewing and prevent people from automatically creating posts just by running a script or the iframe protection like mentioned for the PM's. It's never even close to the query.

Apache mod_ssl vulnerabilities. XAMPP problem. It's not for production anyways.

PHPSESSID session fixation. This means that someone can set the session id using a GET parameter, like

http://example.com?PHPSESSID=h4x0redsessionid

Now, the attacker knows that value and doesn't have to steal it at a later time. But since there is no sensitive data being stored using sessions in my script, this isn't so much a problem. To fix this, set session.use_only_cookies = 1 in php.ini.

User credentials sent in clear text. 48 of these. I actually have it built to be able to use a secure login, but probably won't use it.

The rest were basically all false positives. It says it found sensitive directories, files, ASP.NET files, Access databases, and most anything you can think of. This turns out to just be a simple glitch with mod_rewrite. Here's the line:

RewriteRule ^browse-posts/show-sold(/category/([a-zA-Z0-9-]+))?(/page([0-9]+))?/? browse.php?show=sold&category=$2&page=$4 [L]

I didn't put $ behind the match. So, /browse-posts/show-sold/password.txt would be show a page, and /browse-posts/show-sold/Web.config would show the same thing, /browse-posts/show-sold/CVS/Repository same thing.

Even though there was no real problem, just an annoyance, it was an easy fix:

RewriteRule ^browse-posts/show-sold(/category/([a-zA-Z0-9-]+))?(/page([0-9]+))?/?<b>$</b> browse.php?show=sold&category=$2&page=$4 [L]

Now, /browse-posts/show-sold/password.txt sends a 404.

So, if you don't include the mod_ssl problem, it found 0 vulnerabilities, 1 bug, 1 possible problem, and about 300 false positives, so I'm not really sure of the usefulness of this. If you have an app you want to easily test, it can help, but I don't see this as a sure fire way to test it.