PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Wed Jun 03, 2020 3:03 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Jan 27, 2012 9:46 pm 
Offline
Forum Newbie

Joined: Thu Sep 22, 2011 4:36 pm
Posts: 2
Hey,

I was wondering what the current method to prevent post form tampering is. The below link provides a description of digests and mhash in php, is this the current standard?

http://advosys.ca/papers/web/60-form-tampering.html

thanks in advance for your response


Top
 Profile  
 
PostPosted: Sat Jan 28, 2012 3:59 am 
Offline
DevNet Master
User avatar

Joined: Sun Feb 15, 2009 12:08 pm
Posts: 2794
Location: .za
Good find on the article; until now i haven't considered something like this because i usually call the form on itself thinking it would negate the possibility of messing with the form (apart from attempting to manipulate input).

Edit: I started a thread about if it's possible to spoof $_POST values

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering


Top
 Profile  
 
PostPosted: Sat Jan 28, 2012 9:33 pm 
Offline
Forum Regular
User avatar

Joined: Tue Sep 28, 2010 11:41 am
Posts: 984
Location: Columbus, Ohio
Ever hit a Form based (forget the actual name for it) app on a windows web server? They store a horribly long value of the "state" of your activity. I'm defiantly not a fan of this.

I prefer using $_SESSION to store anything that doesn't need to persist, and if need be encrypt the data staying in there (I have worked in environments where a bad script could read the temp directory that session data is saved in. If I need to encrypt it, I usually also use the person's IP as part of the pepper.

One thing I considered at one point, but never tried it, for more secure needs, is a constantly rotating Pepper. Come to a page, it uses a pepper in $_COOKIE along with like the IP address to decrypt the data. It then generates a new pepper to write into $_COOKIE and then re-write out to $SESSION using that new pepper.

Of course, I would need to test this, make sure it is pretty stable (ie, the possibility of double load on the page, and SESSION or COOKIE updates before the other is also updates and page called again. Highly unlikely, but I would want to protect against that.)

A server environment that isn't locked down to keep a script from only accessing the user's directory can lead to a lot of problems if someone wants to be malicious. Think about it, no matter what type of protection you put in (via PHP script) doesn't matter then cause whoever is hacking in from another account will be able to read the code and see how to use it. (and they can also read your DB logins and use them! All this on top of being able to read session files. I have worked for a company that runs that type of environment, and had to clean up a few times after hacks. Now, not fun for the company, but I'm such a geek for me I had fun tracking it down and fixing it.

-Greg


Top
 Profile  
 
PostPosted: Sun Jan 29, 2012 5:09 pm 
Offline
DevNet Master
User avatar

Joined: Sun Feb 15, 2009 12:08 pm
Posts: 2794
Location: .za
The big issue is that the user doesn't have to use your form to submit data to the process page; what about the following option: If the form is accessed set a value in a session variable. On the processing page check for that variable and if it isn't set it means the process page has not been accessed from your form; is this a valid observation?

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering


Top
 Profile  
 
PostPosted: Sun Jan 29, 2012 7:45 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR
I do not understand the point of this article. Granted, I glossed over it real quick, but it seems that the author is trying to detect tampering with hidden form fields.

My initial response is, WHY IN THE HELL WOULD YOU PERSIST DATA THAT WAY?!

If you are concerned with the user tampering with data on the client side (query string variables, form fields (visible or hidden), or cookie values), dont give them the opportunity. Store that kind of data in a session!


Top
 Profile  
 
PostPosted: Sun Jan 29, 2012 7:52 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR


Top
 Profile  
 
PostPosted: Mon Jan 30, 2012 1:00 pm 
Offline
Forum Contributor
User avatar

Joined: Sat Oct 01, 2011 9:29 pm
Posts: 156
Location: Colorado, USA


Top
 Profile  
 
PostPosted: Mon Jan 30, 2012 2:44 pm 
Offline
Forum Regular
User avatar

Joined: Tue Sep 28, 2010 11:41 am
Posts: 984
Location: Columbus, Ohio
Where I did it, there were others who were higher up who didn't believe in trusting sessions, so i just stayed away from that, Flying Circus, I like that method, will probably switch to something like that. Thanks for the idea!

-Greg


Top
 Profile  
 
PostPosted: Mon Jan 30, 2012 3:31 pm 
Offline
Forum Contributor
User avatar

Joined: Sat Oct 01, 2011 9:29 pm
Posts: 156
Location: Colorado, USA
Tell them the only reason they can't trust their sessions is because they can't trust their developers.
If you know what you're doing, session variables are one of the safest ways to store information temporarily


Top
 Profile  
 
PostPosted: Mon Jan 30, 2012 3:51 pm 
Offline
Forum Regular
User avatar

Joined: Tue Sep 28, 2010 11:41 am
Posts: 984
Location: Columbus, Ohio
Yeah, well there were several things that could have been done more secure there LOL (granted, newer servers are getting done better)

-Greg


Top
 Profile  
 
PostPosted: Mon Jan 30, 2012 11:26 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR


Top
 Profile  
 
PostPosted: Mon Jan 30, 2012 11:37 pm 
Offline
Forum Regular
User avatar

Joined: Wed Mar 05, 2008 11:23 pm
Posts: 732
Location: Sunriver, OR
As an additional side note:

A technique I have tried is the past is to use client side scripts to re-arrange data on form submit. The thought process is that bots/crawlers typically dont download and execute scripts on a page. They just parse the page looking for a form. If form fields exists they get populated and submitted.

However, if on form submit, you use javascript to create a new field called myPassword, then move the value of password to myPassword, you can check server side that password is always empty. We can expect that if a form post arrives and password is not empty, then it was either forged, or sent by a client who has javascript disabled.


Your mileage may vary with the above technique, but it's an interesting think.


Top
 Profile  
 
PostPosted: Tue Jan 31, 2012 12:26 am 
Offline
Forum Regular
User avatar

Joined: Tue Sep 28, 2010 11:41 am
Posts: 984
Location: Columbus, Ohio
Thanks for the bit about the session.save_path, never knew about that and will defiantly put it to use on my server.

The other item of using Javascript I just don't care for myself, because I prefer to rely on JS as little as possible. I know most people have it on anymore, just my "old school" preference of everything should work seamlessly with or without JS (other than things like inline error displaying, ignoring it actually does a page load.) I know there are groups that go heavy one way or another, not trying to get a debate on if you should or not started ;-)


Top
 Profile  
 
PostPosted: Tue Jan 31, 2012 5:50 am 
Offline
DevNet Resident
User avatar

Joined: Sun Sep 03, 2006 5:19 am
Posts: 1579
Location: Sofia, Bulgaria
Not advocating this method of form tampering prevention, but I'd like to point out that the fact that it is using hidden variables for state doesn't make the method less secure than keeping these in the session, since the HMAC key is kept on the server and can't be spoofed.

This is in fact a type of form token, which uses a validity timestamp instead of being a nonce. In various circumstances it may be more user-friendly to use timestamped tokens instead of nonces (or you can issue multiple nonces which is more or less equivalent). I personally think that server-side form tokens are more pleasant to implement, but that's a personal preference, there's nothing wrong with what this guy does theoretically (I haven't read the actual code, there might be security holes in the implementation, but that's another thing)


Top
 Profile  
 
PostPosted: Tue Jan 31, 2012 5:59 am 
Offline
DevNet Master
User avatar

Joined: Sun Feb 15, 2009 12:08 pm
Posts: 2794
Location: .za
The issue i have with the hidden fields method is that those values are known; granted you still don't know how the values are used; how they are put together etc but they are known. Session values are less known (can't be seen when viewing the source) so it adds a bit more security IMO; more things to figure out on how to beat a particular system.

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 5 guests


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 post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group