4

With REST client sessions are not handled by maintaining server side state. Any such state needed for subsequent calls is passed to the client and then passed back to the server as part of those calls.

So what's the standard approach to state that you don't want the client to have?

E.g. I have a resource X, internally instances of this resource have simple names like "A", "B" and "C". Multiple instances of resource X can be associated with a given user - and in each REST call I want to specify which specific instance of X is currently being operated on.

In the simple case I'd just include something like this in my REST calls:

"xId" : "B"

However there are a number of things I want to prevent...

  • I want to prevent the user fishing for other instances, by e.g. specifying arbitrary IDs like "Z" in the their calls.
  • I don't want the internal names of the resources ending up on client machines (these might be useful in attacks via completely different vectors).
  • If a given instance of X is reassigned to another user I want to prevent the old owner using its ID (that they validly obtained) in further calls now that it is no longer assigned to them.

I'm guessing people will reply that there are two issues here:

  • That I'm not talking about session state here but rather the assignment of resources to users and that on the server side I just need to validate that the resource specified in a call is really associated with that user.
  • That there's a separate ID masking issue here - that if I have internal IDs that I don't want exposed to the client I should just create long lived aliases.

Are there a good set of guidelines covering the specific security issues that arise with REST as a result of storing session state on the client side (as opposed to keeping it on the server side)? E.g. the trusted client problem isn't REST specific but perhaps there are REST specific aspects to this and other problems that one should generally be aware of.

In the specific situation I've described I would assign random UUIDs generated by a CSPRNG as aliases to my underlying resources, validate that a given resource is associated with a user when it's specified in a call and assign a new alias to the underlying resource whenever it is reassigned to another user (a step that shouldn't actually be necessary given that one always validates the current association of an ID with a user). However with security I generally find that when non-experts think they've got all the angles covered they're generally wrong!

1

What you are proposing sounds reasonably secure. The one change I would make is to move from UUIDs to a simple 128-bit cryptographically secure random number. I suggest this because, while UUIDs are intended to be unique, they are not designed to be unpredictable. Depending on the UUID implementation details, perhaps an attacker can start to predict subsequent IDs based on having obtained one or more through legal means.

  • Sorry for the late reply - I think I basically covered what you suggest in my question, i.e. I said that one should use a CSPRNG to generate the random UUIDs (by which I meant version 4 UUIDs). Thanks for the reassuring "... sounds reasonably secure." I'm glad nobody has yet jumped in and pointed out anything idiotic in what I outlined :) – George Hawkins Apr 29 '16 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.