Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - Other
Author Message
Dawg
RavenNuke(tm) Development Team



Joined: Nov 07, 2003
Posts: 928

PostPosted: Thu Jan 17, 2008 10:51 pm Reply with quote

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
 
View user's profile Send private message
montego
Site Admin



Joined: Aug 29, 2004
Posts: 9457
Location: Arizona

PostPosted: Fri Jan 18, 2008 7:13 am Reply with quote

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.

_________________
Where Do YOU Stand?
HTML Newsletter::ShortLinks::Mailer::Downloads and more... 
View user's profile Send private message Visit poster's website
Gremmie
Former Moderator in Good Standing



Joined: Apr 06, 2006
Posts: 2415
Location: Iowa, USA

PostPosted: Fri Jan 18, 2008 8:28 am Reply with quote

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.

_________________
GCalendar - An Event Calendar for PHP-Nuke
Member_Map - A Google Maps Nuke Module 
View user's profile Send private message
Dawg







PostPosted: Fri Jan 18, 2008 8:49 am Reply with quote

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
 
kguske
Site Admin



Joined: Jun 04, 2004
Posts: 6432

PostPosted: Sat Jan 19, 2008 8:01 am Reply with quote

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 [ Only registered users can see links on this board! Get registered or login! ]

_________________
I search, therefore I exist...
nukeSEO - nukeFEED - nukePIE - nukeSPAM - nukeWYSIWYG
 
View user's profile Send private message
fkelly
Former Moderator in Good Standing



Joined: Aug 30, 2005
Posts: 3312
Location: near Albany NY

PostPosted: Sat Jan 19, 2008 12:10 pm Reply with quote

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 [ Only registered users can see links on this board! Get registered or login! ] 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.
 
View user's profile Send private message Visit poster's website
montego







PostPosted: Sat Jan 19, 2008 10:58 pm Reply with quote

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????
 
fkelly







PostPosted: Sun Jan 20, 2008 12:18 am Reply with quote

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.
 
montego







PostPosted: Sun Jan 20, 2008 10:58 am Reply with quote

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 [ Only registered users can see links on this board! Get registered or login! ] 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.
 
Dawg







PostPosted: Sun Jan 20, 2008 11:03 am Reply with quote

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
 
Gremmie







PostPosted: Sun Jan 20, 2008 11:18 am Reply with quote

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
 
montego







PostPosted: Sun Jan 20, 2008 11:20 am Reply with quote

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.
 
fkelly







PostPosted: Sun Jan 20, 2008 11:22 am Reply with quote

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.
 
fkelly







PostPosted: Sun Jan 20, 2008 1:45 pm Reply with quote

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.
 
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Security - Other

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©