post forms security - tampering
Moderator: General Moderators
Re: post forms security - tampering
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
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
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: post forms security - tampering
Could you elaborate on this;Mordred wrote:If you store them in a session, you'll need some type of namespacing
“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
Re: post forms security - tampering
On the page you have two forms with two tokens you want to keep in $_SESSION. What are they called?
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: post forms security - tampering
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)
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)
“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
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: post forms security - tampering
Hi Mordred,Mordred wrote:On the page you have two forms with two tokens you want to keep in $_SESSION. What are they called?
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
ThanksI always enjoy reading your posts, I almost always learn something.
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
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.Mordred wrote:ThanksI always enjoy reading your posts, I almost always learn something.
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.
However, i'm not sure you can store arrays in a session; though i've never actually tried it.
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: post forms security - tampering
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 approachMordred wrote:ThanksI always enjoy reading your posts, I almost always learn something.
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
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
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.
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
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-checkMordred wrote:Eh, you're selling yourself short, califdonThis 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.
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
THIS SHOULD BE ENGRAVED ON A PLATINUM PLATE AND MOUNTED ABOVE THE WORK STATION OF EVERY WEB DEVELOPER!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.