4 Replies - 2956 Views - Last Post: 05 September 2010 - 02:10 PM Rate Topic: -----

#1 CodeVillain  Icon User is offline

  • D.I.C Head

Reputation: 11
  • View blog
  • Posts: 143
  • Joined: 10-July 10

SQL Injection Prevention for GET function

Posted 05 September 2010 - 12:17 PM

I just built a simple little search for my site, and it's my first time ever really using GET instead of POST which has me realizing I have no idea how to prevent SQL injection in this sort of fashion. Could anyone give me a hand?

Here's my code for the search.

<?php 
 include("body-parts/connect.php");

 if (strlen ($search) <=2) 
 echo "Search term too short.";
 else
 {
 echo "You searched for $search <hr>";
 
$search_exploded = explode(" ",$search);

foreach($search_exploded as $search_each)
		{
$x++;
if ($x==1)
	$construct .= "keywords LIKE '%$search_each%' ";
else
	$construct .= "OR keywords LIKE '%$search_each%' ";
		}
	$construct = "SELECT * FROM posts WHERE $construct";
	$run = mysql_query($construct);
	
	$foundnum = mysql_num_rows($run);
	
	if ($foundnum==0)
		echo "No results found.";
		else
	{
echo $foundnum . "results found!<p>";
while ($runrows = mysql_fetch_assoc($run))
{
$code = $runrows['code'];

echo "$code";
}
}
}
?>


Is This A Good Question/Topic? 0
  • +

Replies To: SQL Injection Prevention for GET function

#2 daekano  Icon User is offline

  • D.I.C Head

Reputation: 11
  • View blog
  • Posts: 62
  • Joined: 07-July 10

Re: SQL Injection Prevention for GET function

Posted 05 September 2010 - 12:32 PM

It shouldn't be much different than protecting yourself against attacks with POST. You've already begun some validation by checking on the string length of $search.

Here is where you're already performing basic validation/sanitization:
if(strlen($search))


I would recommend trim() and mysql_real_escape_string() as your next methods of sanitizing that data.
Trim should only remove leading and trailing whitespace on the entire string, so your space delimiters should stay intact and your explode function should not be affected.

This post has been edited by daekano: 05 September 2010 - 02:06 PM

Was This Post Helpful? 1
  • +
  • -

#3 JackOfAllTrades  Icon User is offline

  • Saucy!
  • member icon

Reputation: 6078
  • View blog
  • Posts: 23,546
  • Joined: 23-August 08

Re: SQL Injection Prevention for GET function

Posted 05 September 2010 - 12:34 PM

Preventing SQL injection with MySQL pretty much always involves the use of one of several methods, irrespective of from where the user-generated data originates. Either use the mysql_real_escape_string() function (see this tutorial), or ideally using prepared statements, as shown in this tutorial with mysqli, or this tutorial with PDO.
Was This Post Helpful? 1
  • +
  • -

#4 CodeVillain  Icon User is offline

  • D.I.C Head

Reputation: 11
  • View blog
  • Posts: 143
  • Joined: 10-July 10

Re: SQL Injection Prevention for GET function

Posted 05 September 2010 - 12:38 PM

View Postdaekano, on 05 September 2010 - 10:32 AM, said:

It shouldn't be much different than protecting yourself against attacks with POST. You've already begun some validation by checking on the string length of $search.

Here is where you're already performing basic validation/sanitization:
if(strlen($search)


I would recommend trim() and mysql_real_escape_string() as your next methods of sanitizing that data.
Trim should only remove leading and trailing whitespace on the entire string, so your space delimiters should stay intact and your explode function should not be affected.


Much appreciated, I'm just a little concerned I'll muck up the search with character removal but I'm sure I'll manage to figure it out.
Was This Post Helpful? 0
  • +
  • -

#5 daekano  Icon User is offline

  • D.I.C Head

Reputation: 11
  • View blog
  • Posts: 62
  • Joined: 07-July 10

Re: SQL Injection Prevention for GET function

Posted 05 September 2010 - 02:10 PM

I see what you mean, but you should be okay. You could always run some regular expressions to strip out unwanted characters like ", ', =, /, etc. But mysql_real_escape_string performs something that just nullfies them.

I think that in general, people know not to use those characters in their searches. That's a strange thought, but we may have actually trained them. At least, if they do use those characters then they don't expect good results to be returned.

The only thing you're trying to do is protect your database. The only people who are likely to use those characters are those who are trying to exploit vulnerabilities in your code. There's no need to make sure they still get good search results from their injections ;)
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1