"Some Web frameworks use session state to track and hold information about the user throughout their journey through the site, however they go against the RESTful principles and should really be treated as a bug."
I'll bet this guy's not fun to be in design meetings with.
The classic (and best) method for foiling these attacks is to store a special/randomized token in a server-side session, and require that token to be submitted from the client via a standard form, essentially making forged attacks impossible. Take away the ability to store these tokens in some sort of server-side session, and you open your site to attack?
Give a ticket with each response, require a ticket with each request. Tickets are signed with HMAC, dated, and individualized to the user login. Creating a ticket, the server forgets it. Receiving a ticket, the server checks it, creates another, and forgets that.
I don't quite understand how the server would validate the ticket if it's been forgotten. Wouldn't that just allow any forged request to generate a seemingly valid ticket and submit a request like that. Further, excuse my ignorance, but can you explain how HMAC would help in a more user-friendly language than what Wikipedia provides?
To validate the ticket, it looks inside the ticket at the user ID, the timeout date and it checks the signature. HMAC is a lightweight symmetric-key signature. Symmetric keys are OK because the same person is generating and checking signatures. Data plus signature equals proof that "I earlier permitted this". I don't need to remember it in the interim.
A forged request can't guess the HMAC key, and a forged request with an invalid key is refused. A replay is disallowed after the timeout. The server can also keep track of "spent" tickets until they would have timed out, preventing a replay even during the timeout period.
In the case of tickets, the one signing is "this server then" and the one checking is "this server now", with a period of amnesia (about the data, not about the password) in between.
Ahh, my bad. I think I see where you're going with this now. You're basically just remembering the last visit a particular client makes on every request, and then resetting the ticket for the next request correct?
Imagine a disposable photo-ID ticket marked "admit one authenticated client". The bouncer takes it, looks at it, looks at you, tears it in half, and lets you in. You get to make a request, and as you carry the response out of the exit door, a member of staff takes your photo and prints a fresh ticket.
A man in the middle attack won't defeat a signed "cart" object stored in the client's browser. The signature's private key is stored on the server and never appears on the network. This requires no per-session state on the server, just a single key pair.
SSL, on the other hand does nothing to prevent a cross-site attack. Anything that can run code in the client browser can in principle cause it to send a fraudulent shopping cart "securely" to the server.
In his example, where the server maintains the state of the basket, all the requests from the user require a user name and password which will be used to authenticate the user and thus prevent identity forging.
Also the user loses their entire state if they switch web browsers or sit down at a different terminal. Granted they'd have to log back into your site to restore their state but at least there's something there to be restored.
"differ from storing the cart in a user session" I never store anything but sessions in user sessions, carts go in the cart table/whatever. Carts may have a session_id they are associated with, but they are probably keyed to user instead(depends). Probably stored in a cookie(state on the client).
Not saying author is wrong, I just don't get it.
And how come rest folks don't end their resources with a '/'. like http://example.com/users/bob/ The "root" resource ends in a slash. http://example.com/ Having that be inconsistent with other resources always bugs me. I tend to have verbs not end in slash. http://example.com/users/bob/delete Very consistent and orderly to my obcom mind.
I'm in full agreement with him within the frames of the shopping cart analogy/function. I'm trying to think though, of things I currently use a session state for that would suffer under this process.
The cart on client scares me when it has to do with data that isn't trivial. (ie, personal data etc) I don't have these concerns with the "cart on the server" idea, but it does create some interesting issues where devs need to be explicitly aware of who is accessing this data at any given time.
an interesting read but one thing I didn't understand, how is one meant to save the plaintext username & password client side (so as to be able to send them with each request) without putting them in a cookie or requiring that the user's browser is set to 'remember this password' - anyone got any ideas?
In theory by using a cookie which can be verified by any server, but which can only be generated with the user's password (which is never stored in clear text).
In my experience, the browser doesn't reliably send the username and password with each request so you get a bunch of re-queries. Cookies don't have that problem, they're always sent.
At least, that's what I saw on the intranet site I built, switched to authenticating with a login page and cookies instead because of it.
I'll bet this guy's not fun to be in design meetings with.