Hello all. I want to implement a stateless incremental payment dialog in a RESTfull manner like this one: Client --- Server 1) Post Order ---> Return Order Details + Payment Method Form 2) Post Order + Payment Method ---> Return Order Details + Payment Method + Sender Details Form 3) Post Order + Payment Method + Sender Details ---> Return Payment Result
However is the any way how i can be sure that Order was not changed during this client server dialog and still be stateless?
Hello all. I want to implement a stateless incremental payment dialog in a RESTfull manner like this one: Client --- Server 1) Post Order ---> Return Order Details + Payment Method Form 2) Post Order + Payment Method ---> Return Order Details + Payment Method + Sender Details Form 3) Post Order + Payment Method + Sender Details ---> Return Payment Result
However is the any way how i can be sure that Order was not changed during this client server dialog and still be stateless?
Include and require a digitally signed hash key in a hidden field and verify on that.
- Best regards, Nikolay Pavlov. <<<-----------------------------------
--Greg
Thanks Gregory. I have come to the same conclusion. I just want to be sure that there is know other known way for such things. Thanks again.
I forget to ask. Is there any plug-in for that?
I absolutely don't mean to spread FUD here, but isn't that what Rails 2.0 cookie-based sessions do, and isn't there some way (not obvious to my sleep-addled brain) to exploit that?
Again: The answer may very well be "no"! There was a really really long discussion on rails-core about this when cookie-based sessions first landed and I just don't remember the conclusions. I'm hoping someone who remembers that discussion can jump in.
You can't create, modify, or otherwise forge a message, but you can grab a valid message and 'replay' it later. To avoid a replay attack, you need to include, say, a nonce in the message and check it against a list of used nonces. Already used the nonce? Replay attack! Reject message.
jeremy
>> However is the any way how i can be sure that Order was not changed during >> this client server dialog and still be stateless? > > Include and require a digitally signed hash key in a hidden field and > verify on that.
I absolutely don't mean to spread FUD here, but isn't that what Rails 2.0 cookie-based sessions do, and isn't there some way (not obvious to my sleep-addled brain) to exploit that?
Again: The answer may very well be "no"! There was a really really long discussion on rails-core about this when cookie-based sessions first landed and I just don't remember the conclusions. I'm hoping someone who remembers that discussion can jump in.
You missed the "stateless" requirement.
Jay Levitt |
--Greg
However is the any way how i can be sure that Order was not changed during this client server dialog and still be stateless?
Include and require a digitally signed hash key in a hidden field and verify on that.
I absolutely don't mean to spread FUD here, but isn't that what Rails 2.0 cookie-based sessions do, and isn't there some way (not obvious to my sleep-addled brain) to exploit that?
You missed the "stateless" requirement.
No, I saw it - but I also saw the "how can I be sure" requirement, and I wasn't sure that cookie-based solutions met both.
From what Jeremy says about using the nonce - and yes, that's exactly what I was thinking of - it really depends on the application; if a replay attack could cause something bad to happen, then you simply *can't* be totally stateless.
Looking at the OP's requirements:
1) Post Order ---> Return Order Details + Payment Method Form 2) Post Order + Payment Method ---> Return Order Details + Payment Method + Sender Details Form 3) Post Order + Payment Method + Sender Details ---> Return Payment Result
a replay at (2) *could* result in someone sending along a digitally signed key that says "Order 1 large-screen TV, my American Express is XXXX" and getting back a nice "Sure thing, we've verified that digital signature, what address shall we ship to?" dialog.
So it's something to consider in the design.
Well I was not totally clear. "Sender Details" here means Sender billing information. So every time you are replaying (2) you are getting (3) and every time you are replaying (3), you are getting the bill or redirection to some payment gateway. Of course i could be wrong...
By the way on (2) we could include one of those fancy images with zapped digits in a response and a signature of (order + digits_on_image). Than on (3) we could compare received signature and resigned (order + received_digits). Also we could invalidate the replay in time by adding something like Time.now.strftime("%Y%m%d%H").to_i to signature. And still be stateless.
Cool, sounds like you've already taken replays into account. That's all I was suggesting!
By the way on (2) we could include one of those fancy images with zapped digits in a response and a signature of (order + digits_on_image). Than on (3) we could compare received signature and resigned (order + received_digits).
You're talking about CAPTCHAs... they can be helpful in some cases, but there are a few drawbacks, including: - They're not accessible, so you need to provide some alternative for the visually-impaired - They're getting easier and easier to OCR - If someone really wants to break your CAPTCHAs, all they have to do is redisplay them somewhere else (porn sites, Amazon Mechanical Turk) and get THEIR humans to solve them
Google for CAPTCHAs before you go that route, just so you understand the issues.
Also we could invalidate the replay in time by adding something like Time.now.strftime("%Y%m%d%H").to_i to signature. And still be stateless.
Not a bad idea at all.