Form Input and Security.....

Posted: Thu Jan 17, 2008 10:51 pm

I have a form that takes Day, Month and Year.....then you click on an image (for lat and long).....that data is run through the rest of the script.

Do I need to secure this down in any way?

I am close to releaseing this and I want to make sure I have everything JUST so....

BTW....0 Errors/0 Warnings

Would one of you GREAT GURUS consider giving this thing the once over?

Smile

Dawg

registered · Posted: Fri Jan 18, 2008 7:13 am

ALL input must be reviewed and screened/sanitized as needed. I will assume that these are integer values and so this is what I personally would do/watch out for:

1. I would definitely cast them as integers whether using (int) or intval() on the input. ALWAYS.

2. I would also check the boundary conditions. For example, will a 0 or negative number in any of these cause an issue in your code? Or, will a higher number than allowed cause an issue? If so, do not allow these and throw the form back to them to re-enter.

3. Regarding the lat/long, even though they are clicking on an image, remember that anyone can fashion a GET/POST string for ANY of your form input variables, so since these a probably integers, the same feedback as above applies.

Hope this helps.

registered · Posted: Fri Jan 18, 2008 8:28 am

That's good advice. I would add that you should code as if register globals was off. Even though Nuke turns it back on, you should always retrieve user input from the super globals ($_GET, $_POST, etc) as appropriate. Don't just assume everything is global like most of core nuke.

Posted: Fri Jan 18, 2008 8:49 am

montego wrote:

1. I would definitely cast them as integers whether using (int) or intval() on the input. ALWAYS.

I had them as int to start but Tidy kicked it out....I will revist this.

montego, Gremmie, Thank You your responce!! I will go have good look at what I have done. I am trying to be a GOOD LITTLE CODER.....and do it the right way.

To bad there is not a "Tidy" for PHP that points out these type of things....

Dawg

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

Not sure why Tidy would kick it out, but as for Tidy for PHP, there are editors that can help by using code snippets and suggesting corrections as you code. For more information, see http://www.php-editors.com/

Posted: Sat Jan 19, 2008 12:10 pm

Quote:

remember that anyone can fashion a GET/POST string for ANY of your form input variables

Hope you don't mind if I jump on this thread with a few additional questions. But first to step back a bit.

It seems to me that there are two distinct ways to try to attack a form. One is to use the legitimate form that's on a Nuke page and in one or more of the fields, put hack codes such as script equals ... bla bla bla. Then submit it. The other is to forge the whole form. You can do this be either doing a view source of the form structure and then simulating it on your own site and submitting it from there ... or possibly by downloading the Nuke source code and then making up a forged form from that. In either of these forged cases you could treat integer values as text or even text areas and no one would be any wiser unless validation was done.

However, and this is where my question lies, a form submitted from another site is going to get caught out by the XSS filters in Sentinel, is it not? It will always have a http://someother_site in the http header. So, to get around this the attacker would also have to forge the header, no? Is this possible? I don't mean to be naive, I'm just trying to understand whether we need to protect against forged and manipulated forms coming from other sites or whether we can trust that the xss filters assure the form comes from our own domain.

Posted: Sat Jan 19, 2008 10:58 pm

Absolutely headers can be forged, but I am not sure where you are going with this fkelly. The forged form may have a different referrer, but the post action would be the same as if it came from the real site????

Posted: Sun Jan 20, 2008 12:18 am

Not exactly M. Let's say on the real site you had a field with a max length of 8. If the form was filled out from the real site (your Nuke site) it couldn't exceed that. Likewise if if was a checkbox it would only be on or off. From a forged site (or really a forged form from a fake site pretending to you yours) the field value could be anything. A checkbox on the real form could be a text field in the forged form. If the validation just used the GPC variable it would get whatever was in that POST value. If the validation didn't carefully evaluate each field it could easily be hacked.

I'm not saying you don't need to do validation on form fields from your own site but the possible issues are much greater if the hacker can forge the form and make the fields be whatever he wants. To do that, if the XSS filters work properly, he would have to forge the HTTP header also to make it appear that the form came from your own site. I think.

Posted: Sun Jan 20, 2008 10:58 am

fkelly,

I was addressing your comment here:

Quote:

However, and this is where my question lies, a form submitted from another site is going to get caught out by the XSS filters in Sentinel, is it not? It will always have a http://someother_site in the http header. So, to get around this the attacker would also have to forge the header, no? Is this possible? I don't mean to be naive, I'm just trying to understand whether we need to protect against forged and manipulated forms coming from other sites or whether we can trust that the xss filters assure the form comes from our own domain.

I don't see how the referrer will have anything to do with NukeSentinel unless the forged site is sitting on a domain that is being blocked within the referrers.

I guess that is where my confusion is.

However, what you say about the variables not necessarily being an integer vs. text definitely does apply. In the case of Dawg's usage being integer, as long as "0" does not cause his site to do something it shouldn't, then having text data in those variables will not an issue. But, yes, you must be aware of the issue that you are raising.

Posted: Sun Jan 20, 2008 11:03 am

Would one of you be kind enough to show an example the correct way to take input in a form?

I want to make I do it correctly.

Dawg

Posted: Sun Jan 20, 2008 11:18 am

There really isn't a correct way...but

Get the data out of $_POST if that is your form method.

Sanitize it. What that means depends on what you are expecting. If you are expecting integers, convert them to integers with intval(). That will turn any text into 0. If you are expecting text, apply any checks as you see appropriate. Check it for length. If it is an email, validate it. Strip HTML from it, etc.

Finally, if you are going to then insert textual data into the database, make sure you run addslashes() or mysql_real_escape_string() on it to prevent SQL injection.

Get a good book on PHP/MySQL. Smile

Posted: Sun Jan 20, 2008 11:20 am

Dawg, no-one can show you just one way to do something and have it work for all instances, so I think you have to take the info above and apply it to any form input and backend processing code that you have. For the ONE example of wanting to ensure something is an integer, you COULD do this:

$someIntVar = intval($_POST['page_var_name']);

Just keep in mind that if $_POST['page_var_name'] has text values in it, I believe PHP will assign a 0 value to $someIntVar. Therefore, your code needs to not do something haywire in that instance. You may also want to do boundary checking on that integer too as I mentioned above.

This is just ONE way of dealing with input that should be an integer.

Posted: Sun Jan 20, 2008 11:22 am

Make a list of all the input fields on your form. Each one will have a name.

At the start of the program that processes the form do a
var1 = filter($_POST['field1']) ...
varn = filter($_POST['fieldn'])

so that you appropriately filter each field from the form. You may need multiple filters for some fields. For instance, earlier in the thread M. I think said that if you have a range of values on an integer you should not only filter for intval but also that the returned value is in the range you expect (require, really). Likewise if you don't want html and a text field can't be more than 25 characters you might need to do check_html and also check for the length. You also may need to do an isset check before you do a $_POST on certain field types ... I believe it is checkboxes that aren't passed over unless a value is checked in them and you will get a warning unless you make sure they are there before you try to post them.

There is considerable debate right now about exactly what the right filter are to apply, for instance to screen out html or to sanitize it but there is no debate at all that all input must be filtered.

Posted: Sun Jan 20, 2008 1:45 pm

LOL, I'm picturing Gremmie, M. and fkelly all sitting at their computers typing a response at the same time. I guess Gremmie types fastest and fkelly needs to go back to typing school.