SQl Injection Protection

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
spacebiscuit
Forum Contributor
Posts: 390
Joined: Mon Mar 07, 2005 3:20 pm

SQl Injection Protection

Post by spacebiscuit »

Hi,

I have a comments section on my site. When the form is submiited I filter teh text for malicious code - keywords such as "frame" "script" and characters such as ";"

Is there anything else that I can do to make the script more secure - the variables are passed as unencoded POST variables via an HTML script.

I frequently get spammy messages that say things like:

"great+resources+thanks+for+posting"

Notice the plus signs in place of the spaces - is this anything to worry about or is a potential hacker trying the system for weaknesses.

Any feedback would be appreciated.

Thanks!
User avatar
twinedev
Forum Regular
Posts: 984
Joined: Tue Sep 28, 2010 11:41 am
Location: Columbus, Ohio

Re: SQl Injection Protection

Post by twinedev »

Some simple items:

The main "danger variables" (ones you can never trust as the user can set their value):
$_POST, $_GET, $_COOKIE, $_SERVER['PHP_SELF'], $_SERVER['HTTP_REFERRER'], $_SERVER['HTTP_USER_AGENT']

Any data that comes from these variables, before going to a database get, if you are using mysql_* functions, wrap it with mysql_real_escape_string()

When outputting data that came from these variables (or data from a database created from them):
1. As HTML or inside attributes such as ALT="" for image, VALUE="" for inputs and CONTENT="" for meta tags, wrap the data with htmlspecialchars($var,ENT_QUOTES)
2. If you are using it as part of a URL (ex link, src value) wrap it with urlencode

If you are getting a bunch of random posts, then there are a couple of things, depending on what your site is based on. Using word press, well that is open source code and it is widely known where to just directly post data to the site to get it to accept it. There are plugins I assume to limit this. But if it is a site you programmed yourself before going the captcha route (this IMO should be one of the last things to try) here are some suggestions:

1. Honeypot - This generally stops bots that go to your site auto submit the form. Add a field, called something like URL (something they would really want to fill in), style it so that it is not visible on the screen. Make sure for accessibility, you add a label that says that the field should be left blank. Then on the code that processes the form, if this field doesn't exist or it does but it isn't blank, don't accept the form submission

2. Time out - If someone writes a bot to just flat out POST to your site, add a field in the form that is the current timestamp. Then when the form is submitted, only accept it if it is within a certain period of time (say, an hour). The direct posting of data will only work for that much time. Now someone looking may recognize the timestamp, so use a simple function to convert it to something very difficult, and then once submitted, convert it back to a number. (See viewtopic.php?f=1&t=132062 for my functions to do this)

Between these two, they can cut down on a lot of automated spam posts. But keep in mind there are a bunch of people out there that get paid a few pennies to submit links to forums...

-Greg
User avatar
tr0gd0rr
Forum Contributor
Posts: 305
Joined: Thu May 11, 2006 8:58 pm
Location: Utah, USA

Re: SQl Injection Protection

Post by tr0gd0rr »

@twindev Thanks for the form tips. Very cool!
spacebiscuit
Forum Contributor
Posts: 390
Joined: Mon Mar 07, 2005 3:20 pm

Re: SQL Injection Protection

Post by spacebiscuit »

Thanks for the lengthy tutorial I am gonig to implement a few of those messures.

I have also noticed that if I get the POST method on my form the variables are not seen in the URL. Is this therefore more secure? It seems so or are there other issues related to this method of passing variables?

Thanks.
User avatar
twinedev
Forum Regular
Posts: 984
Joined: Tue Sep 28, 2010 11:41 am
Location: Columbus, Ohio

Re: SQl Injection Protection

Post by twinedev »

It is only more secure in terms of someone who doesn't know anything is less likely to figure out how to change things. If it is in the URL then they can see the values and may be more tempted to tweak them. Other than that, not one bit more secure using $_POST over $_GET. I can change information on both of them.

-Greg
spacebiscuit
Forum Contributor
Posts: 390
Joined: Mon Mar 07, 2005 3:20 pm

Re: SQl Injection Protection

Post by spacebiscuit »

But like you saw, only if you know the variables being used right?

The fact that POST does not make the variables visible in the URL string is more 'secure', is that correct?

Thanks.
User avatar
twinedev
Forum Regular
Posts: 984
Joined: Tue Sep 28, 2010 11:41 am
Location: Columbus, Ohio

Re: SQl Injection Protection

Post by twinedev »

Again, only to those who don't know what they are doing and don't want to do minimal looking (view source, firebug, fiddler, the last two allow the user to easily change post data. (kinda as usefull as setting javascript to intercept RIGHT CLICK's to "protect" content, the people it protects you from won't know enough to be a bother.

In general, I do not use GET for any forms, except for a search box, or if pagination ends up using a <select> to choose page number and/or sorting information. Mainly it just keeps the URL cleaner (and think, if someone fills out a form, and they bookmark the result, each time they go to the bookmark, your script will think they are submitting the form.

-Greg
Post Reply