Page 1 of 2

post forms security - tampering

Posted: Fri Jan 27, 2012 8:46 pm
by furball
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

Re: post forms security - tampering

Posted: Sat Jan 28, 2012 2:59 am
by social_experiment
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 viewtopic.php?f=34&t=134131

Re: post forms security - tampering

Posted: Sat Jan 28, 2012 8:33 pm
by twinedev
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

Re: post forms security - tampering

Posted: Sun Jan 29, 2012 4:09 pm
by social_experiment
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?

Re: post forms security - tampering

Posted: Sun Jan 29, 2012 6:45 pm
by flying_circus
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!

Re: post forms security - tampering

Posted: Sun Jan 29, 2012 6:52 pm
by flying_circus
social_experiment wrote: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?
That is a valid observation. I use form nonces (Nonce = Number Used Once). I tie a unique, timestamped, nonce to each user session and then put that as a hidden form field in the form. When the user submits the form, the nonce must match what is stored in the users session. If they alter the nonce to a value the does not exist in their session, then the request is rejected. Of course, upon the 1st nonce match, it is important to remove the nonce from their session.


If the request is forged remotely (ie, the form was not accessed from my server) the user will not have a session (or stored nonce) and the request will be rejected.

Re: post forms security - tampering

Posted: Mon Jan 30, 2012 12:00 pm
by egg82
flying_circus wrote: That is a valid observation. I use form nonces (Nonce = Number Used Once). I tie a unique, timestamped, nonce to each user session and then put that as a hidden form field in the form. When the user submits the form, the nonce must match what is stored in the users session. If they alter the nonce to a value the does not exist in their session, then the request is rejected. Of course, upon the 1st nonce match, it is important to remove the nonce from their session.


If the request is forged remotely (ie, the form was not accessed from my server) the user will not have a session (or stored nonce) and the request will be rejected.
That, sir, is absolutely brilliant. I can't believe I never thought about POST tampering.
I'm going to have to steal that idea for my next project!

Re: post forms security - tampering

Posted: Mon Jan 30, 2012 1:44 pm
by twinedev
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

Re: post forms security - tampering

Posted: Mon Jan 30, 2012 2:31 pm
by egg82
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

Re: post forms security - tampering

Posted: Mon Jan 30, 2012 2:51 pm
by twinedev
Yeah, well there were several things that could have been done more secure there LOL (granted, newer servers are getting done better)

-Greg

Re: post forms security - tampering

Posted: Mon Jan 30, 2012 10:26 pm
by flying_circus
Hey guys, glad I could help!

I would make a note on sessions (in general).
  • Note
  • File Based: (default PHP behavior)
    It is a security MUST to change the default storage directory. You can easily do this at runtime by setting the configuration option "session.save_path". Make sure the path you choose is located within your home directory but below the web root.
  • Session Based: (preffered)
    I like creating a database driven session handler, and best of all, it is REALLY simple to do. Soon there will be a sessionHandler class available in PHP. Until then, there is a lot of good information here:
    http://www.php.net/manual/en/function.s ... andler.php

Re: post forms security - tampering

Posted: Mon Jan 30, 2012 10:37 pm
by flying_circus
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.

Re: post forms security - tampering

Posted: Mon Jan 30, 2012 11:26 pm
by twinedev
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 ;-)

Re: post forms security - tampering

Posted: Tue Jan 31, 2012 4:50 am
by Mordred
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)

Re: post forms security - tampering

Posted: Tue Jan 31, 2012 4:59 am
by social_experiment
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.