[SOLVED] Site finished, need some testing before release

[Dragen]

Hi,

After a very long time working on my online shop I'm finally ready to release it, but need to see how secure it is first.

Can anyone please see if the site has any sql etc exploits or anything.

I've currently got error_reporting set to 'E_ALL' for testing purposes, but that will be changed on release.

 

Here's the uri: http://www.gimpcrafts.co.uk/

 

If you don't want to register your own account, you can use these details:

username: dummy

Password: Account1

(Note the capital 'A')

[Coreye]

Full Path Disclosure:

http://www.gimpcrafts.co.uk/search/?keys[]

Warning: urldecode() expects parameter 1 to be string, array given in /home/fhlinux197/g/gimpcrafts.co.uk/user/htdocs/search.php on line 34

[Dragen]

Thanks for the feedback!

I've fixed that problem and a couple of others that you found, such as an item not being displayed if it contains strange characters in the name.

 

Can anyone find any other problems?

[Adam]

Not a hack or anything but when sending an email it's displaying..

 

Warning: Missing argument 4 for messagesend::message_pm(), called in /home/fhlinux197/g/gimpcrafts.co.uk/user/htdocs/ac/incs/messages.php on line 287 and defined in /home/fhlinux197/g/gimpcrafts.co.uk/user/htdocs/incs/mailsend.php on line 112

 

Adam

[Dragen]

Thanks for that! I've sorted it now

[waynew]

See here.

 

Yoiu seem to have magic quotes enabled? Either that or you're using addslashes?

[Dragen]

strangely enough that link gives a blank page :/ Not sure why, but I'll look into it.

[Maq]

Running SQL Inject Me on your homepage gives me 68 failures...

[Dragen]

Running SQL Inject Me on your homepage gives me 68 failures...

Thanks Maq,

Could you please explain these results to me? I've just run sql inject me and it's brought up all of these failures, but none of them actually seem to work..

I've attached an image of my results for the search form. If I use any of the values that it's tested and failed on, I get no negative effects. Nothing happens. It just seems to work normally as I would expect.

 

[attachment deleted by admin]

[Dragen]

Can anyone explain why I'm getting these sq injection results? I can't seem to get them to have any effect on my page at all, so I'm wondering if Sql Inject Me is giving false results?

[darkfreaks]

if your running a function like

 

<?php

function sanitize($text){

$text=mysql_real_escape_string(trim($text));
$text.= strip_tags('allowed tags',$text);
return $text;
}
?>

 

bets are safe that it is just false results 

 

but usually its an indicator that you have not called that function or properly sanitized certain variables

 

 

 

[Dragen]

Thanks.

I check most results and all database queries are made using PDO which, from what I've read, escapes all code if I do it like this:

<?php
$id = 'somevar';
try{
$stmt = $dbh->prepare("SELECT * FROM `table` WHERE `id` = :id");
if($stmt->execute(array(':id' => $id))){
	return $stmt->fetchAll();
}
}catch(PDOException $e){
return $e;
}
?>

[darkfreaks]

this might explain a bit more about SQL injection with PDO

 

http://ezinearticles.com/?SQL-Injection-Protection-in-PHP-With-PDO&id=1815110

[Dragen]

Thanks again

So does that mean that PDO does stop SQL, but not cross site scripting and other methods?

[darkfreaks]

PDO does not stop ALL types of injection you are right there , using PDO prepared statements would help cutdown the 60 injection leaks you currently have

 

PDO Prepared statement Example:

 

$sql = "SELECT firstnme, lastname FROM employee WHERE bonus > ? AND bonus < ?";
$stmt = $conn->prepare($sql);
if (!$stmt) {
  // Handle errors
}

// Explicitly bind parameters
$stmt->bindParam(1, $_POST['lower']);
$stmt->bindParam(2, $_POST['upper']);

$stmt->execute($stmt);

// Invoke statement again using dynamically bound parameters
$stmt->execute($stmt, array($_POST['lower'], $_POST['upper']);

[darkfreaks]

also i worded that wrong you already are using prepared statements but binding the WHERE param might help cut down on injection but that is from what i have read

[Dragen]

Yeah, I'm using prepared statements for all PDO statements.

I'm also using a mixture of

$stmt->execute(array(':id' => $id))

and

$stmt->bindParam(':id', $id);
$stmt->execute()

The second one is using the bindParam() variable and the first one I'm binding in the execute statement, which I'm sure has the same effect as bindParam?

[darkfreaks]

yeah so basically you have all that already

 

The inherent security in using prepared statements sounds great, but developers should not let PDO and other abstraction layers/prepared statement implementations lull them into a false sense of security. Untrusted data should always be validated and sanitised, PDO is just another line of defense. It doesn't cover the territory of a multitude of other input validation vulnerabilities like cross site scripting, but it does do a good job of protecting applications against SQL injection. The best strategy is only allowing known good data by whitelisting characters and matching input data against regular expression patterns, then using prepared statements to catch anything SQL injection-wise that the input validation misses, all in conjunction with a web application firewall like ModSecurity.

[Dragen]

Cool, that's good to know.

 

Thank you to everyone who has helped! After some last minute changes I've now released the site to the public: www.gimpcrafts.co.uk

 

Thanks again