Page 2 of 2

Re: post forms security - tampering

Posted: Tue Jan 31, 2012 5:15 am
by Mordred
For that purpose it's not important if the token parameters are known or not, it is important that they are tamper-proof - this is what HMAC signing does.
Storing it in form hidden vars allows you to easily serve multiple forms on a page with different tokens but same var names to be checked server-side. If you store them in a session, you'll need some type of namespacing

Re: post forms security - tampering

Posted: Tue Jan 31, 2012 6:14 am
by social_experiment
Mordred wrote:If you store them in a session, you'll need some type of namespacing
Could you elaborate on this;

Re: post forms security - tampering

Posted: Tue Jan 31, 2012 6:27 am
by Mordred
On the page you have two forms with two tokens you want to keep in $_SESSION. What are they called?

Re: post forms security - tampering

Posted: Tue Jan 31, 2012 6:49 am
by social_experiment
Ok, i see what you mean; thanks for clearing it up

Thinking about multiple forms on a single page however i think it could still use a single session value as the session value in this case is only used to determine that the processing page was accessed from the page actually containing the form (and not a spoofed page)

Re: post forms security - tampering

Posted: Tue Jan 31, 2012 3:37 pm
by flying_circus
Mordred wrote:On the page you have two forms with two tokens you want to keep in $_SESSION. What are they called?
Hi Mordred,

I always enjoy reading your posts, I almost always learn something.

I've built a nonce manager, and the nonce is also tied to a destination url.

Not only must the user have a session with the matching nonce, the post must also have been submitted to the correct destination and within the allotted amount of time. The nonces are also only good on the next page request.

Program flow looks something like:

Initial Request:
- Server response renders (n) number of forms, assigning each a hidden field with name "nonce" and a token value. The nonce object is created on the server containing token, timestamp, and destination url. These objects get stored in session data in a shutdown function.

2nd Request:
- Startup function reads all nonces from session data into temporary variable and deletes all nonces from session data.

- If is post request, check that a nonce field exists, that the token exists within collection of nonces in the temp variable.
- If it does, compare request uri with nonce destination. If they dont match, reject, if they do, check against timestamp for window of opportunity.


This isn't really a reply directly to anything you said, but I'm always looking for a better way.

Re: post forms security - tampering

Posted: Wed Feb 01, 2012 4:17 am
by Mordred
I always enjoy reading your posts, I almost always learn something.
Thanks :)

What you describe sounds good to me: just store all nonces together (with no particular names, just dump them in an array) and check if ANY matches. Definitely solves the 'namespacing' problem and also allows for nice generally working code snippets (not custom code in every form or somethin). The only "problem" I see with your solution is that since you delete all nonces (and not just the one that has been used for the request) it is not possible to use forms in your application from multiple windows, since the submission of the first one will invalidate the token of the second one. You could simply not do that - I can't see a benefit from invalidating the other tokens.

Re: post forms security - tampering

Posted: Wed Feb 01, 2012 12:38 pm
by egg82
Mordred wrote:
I always enjoy reading your posts, I almost always learn something.
Thanks :)

What you describe sounds good to me: just store all nonces together (with no particular names, just dump them in an array) and check if ANY matches. Definitely solves the 'namespacing' problem and also allows for nice generally working code snippets (not custom code in every form or somethin). The only "problem" I see with your solution is that since you delete all nonces (and not just the one that has been used for the request) it is not possible to use forms in your application from multiple windows, since the submission of the first one will invalidate the token of the second one. You could simply not do that - I can't see a benefit from invalidating the other tokens.
I would agree with this. I think the "workaround" for that would be to store all of the nonces created in an array and remove the array when done.
However, i'm not sure you can store arrays in a session; though i've never actually tried it.

Re: post forms security - tampering

Posted: Thu Feb 02, 2012 10:48 pm
by flying_circus
Mordred wrote:
I always enjoy reading your posts, I almost always learn something.
Thanks :)

What you describe sounds good to me: just store all nonces together (with no particular names, just dump them in an array) and check if ANY matches. Definitely solves the 'namespacing' problem and also allows for nice generally working code snippets (not custom code in every form or somethin). The only "problem" I see with your solution is that since you delete all nonces (and not just the one that has been used for the request) it is not possible to use forms in your application from multiple windows, since the submission of the first one will invalidate the token of the second one. You could simply not do that - I can't see a benefit from invalidating the other tokens.
I've been trying to figure out if this is a bug or a feature. It does seem more intuitive to allow multiple windows. I guess I'll have to give some more thought to my approach :)

Re: post forms security - tampering

Posted: Thu Feb 02, 2012 11:40 pm
by califdon
You guys are above my pay grade on this stuff, and you probably know about this, too, but just in case it has slipped by any of you, there's a add-on for Firefox browser called Tamper Data. It enables you to view--and modify--form data sent by the POST method. I have occasionally found it helpful in debugging something like a payment processing system. https://addons.mozilla.org/en-US/firefo ... mper-data/

Re: post forms security - tampering

Posted: Fri Feb 03, 2012 3:37 am
by Mordred
Eh, you're selling yourself short, califdon :) This is a good reminder, thanks.

When you write security code it's imperative to test it - tools like tamper data or a pentesting proxy like Burp or Paros are essential to that!
Remember: if you haven't tested your code, it is not working! Doesn't matter if you've written similar code before, if you've read it carefully and are 100% sure that it's correct, if a guy on a forum told you it's good or if the ghost of your grandgrandgrandgrandfather came and told you the code is right - until you've tried it with both valid and invalid data, it is not working, period.

Re: post forms security - tampering

Posted: Fri Feb 03, 2012 10:11 am
by egg82
Mordred wrote:Eh, you're selling yourself short, califdon :) This is a good reminder, thanks.

When you write security code it's imperative to test it - tools like tamper data or a pentesting proxy like Burp or Paros are essential to that!
Remember: if you haven't tested your code, it is not working! Doesn't matter if you've written similar code before, if you've read it carefully and are 100% sure that it's correct, if a guy on a forum told you it's good or if the ghost of your grandgrandgrandgrandfather came and told you the code is right - until you've tried it with both valid and invalid data, it is not working, period.
100% agree with this. I cannot tell you how many times i've almost failed my homework because of a mistype or something that I overlooked. Good thing I always check and re-check :D

Even for those of you that don't have to worry about failing classes... If you have a syntax error in a popular website, tickets/emails or whatever you use as a "contact me" system will be flooded. It's not pretty, i've seen it.

Re: post forms security - tampering

Posted: Fri Feb 03, 2012 12:36 pm
by califdon
Mordred wrote:When you write security code it's imperative to test it - tools like tamper data or a pentesting proxy like Burp or Paros are essential to that!
Remember: if you haven't tested your code, it is not working! Doesn't matter if you've written similar code before, if you've read it carefully and are 100% sure that it's correct, if a guy on a forum told you it's good or if the ghost of your grandgrandgrandgrandfather came and told you the code is right - until you've tried it with both valid and invalid data, it is not working, period.
THIS SHOULD BE ENGRAVED ON A PLATINUM PLATE AND MOUNTED ABOVE THE WORK STATION OF EVERY WEB DEVELOPER!

:D