0

I am creating a RESTful API-centric web application. Once a user logs in they will receive a session id and login key that will be used for accessing their data until their session expires. The web application (and possibly the mobile applications) will call an API every page load to get user information if a session is saved in the memory. I am working on optimizing this API call as much as I can, and I wonder if it makes sense to cache this information.

Every table with user data contains a updated timestamp (triggered on every Postgres update). So I could modify the API to accept an optional cache_timestamp parameter. The API would first check to see if any of the user data's tables have been modified since that timestamp. If they have, then it would return the updated user data; if not, it would return a 304 not modified and the application would use the cache.

My question is what information is too sensitive to save in memory (using PHP sessions). Currently the information contains things like profile (name, company, etc), contact (email, phone), settings (newsletter, notifications), and payment info (plan, trial, and an customer ID that refers to Stripe).

The only thing that I think would be on the edge is payment info, but they shouldn't be able to access any data from Stripe unless my API keys are compromised.

Gumbo
  • 643,351
  • 109
  • 780
  • 844
Sam
  • 20,096
  • 2
  • 45
  • 71
  • 1
    This seems to me like a bad question.. It falls under 'Not constructive' of the close vote options, because it 'solicits opinion/debate'. – Daedalus Apr 07 '13 at 04:51
  • I can see it being an opinion. But I honestly don't know how browser sessions work, so I don't know if they can be deemed safe for storing user info (not passwords or credit cards). – Sam Apr 07 '13 at 04:52
  • Hate to tell you...but if you're handing out session IDs, it's almost definitely not RESTful. :P – cHao Apr 07 '13 at 04:56
  • 1
    The point here is, many can have differing opinions, and thus it can solicit extended discussion or debate.. That isn't the purpose of SO. – Daedalus Apr 07 '13 at 04:56
  • @cHao -- if the user has to provide a session id and a key every time he wants to access or modify user information, how is this different than providing username and password for every request? This way the information the client doesn't have to keep a user's password in storage and the server can expire sessions after different times. Is there a way to make this more RESTful? Doesn't oAuth work similarly? – Sam Apr 07 '13 at 05:06
  • @SamSullivan: It's different in that a session ID is basically a handle to transient state on the server. With REST, "statelessness" is a primary goal -- the very idea of "logging in" is broken, as the server shouldn't even care about the client between requests. Any information needed to process a request should either be a "resource" (read: be persistent, and have a URL), or be part of the request itself. – cHao Apr 07 '13 at 20:28
  • @SamSullivan: Also, HTTP doesn't have a built-in method for authenticating session IDs and login keys, whereas for username/password it does. That's just a minor gripe, though, as you could easily consider a login key as a password... – cHao Apr 07 '13 at 20:52
  • @SamSullivan: As for making it more RESTful, don't use sessions. If you don't want to give up the idea of login keys, then semantically, i guess you could consider "logging in" to be posting new login key data, which would create a key and return its info. In that case, the key should be a resource on the same level as, say, the password. You could even consider it a password, if you wanted...but the key (and maybe the username of its creator) would be all you need in order to authenticate. For key life, that should be a property of the key itself rather than a function of PHP's forgetfulness. – cHao Apr 07 '13 at 21:21

2 Answers2

2

I'm not a Security expert, but since the sessions are stored on the server, the only way for an attacker to access the data is to have gained some privileges already.

You can look at this interesting post PHP Session Fixation / Hijacking about how to secure more your sessions.

If the user's session got hijacked, then there is nothing to do, the attacker will access the data like if it was the user in question.

If the attacker can exploit a fail related to your server, then he should probably be able to read the session data (which is stored serialized in some files by default).

So, crypting the sensitive data, can prevent him from reading it raw.

Community
  • 1
  • 1
epicdev
  • 922
  • 4
  • 10
1

My opinion is also same, Payment info should be store in the Session variable, but then you are saying it's not accessible without API key. I think you are at safe side.

roshan lal
  • 325
  • 1
  • 8
  • Payment info should or shouldn't be stored? You would only be able to access the data with the API key, but then it would be stored in a browser's session. Is this vulnerable? – Sam Apr 07 '13 at 04:49
  • 1
    Payment information is sensitive data so store it in session variable. Good practice not to store sensitive data in browser cache. Also please refer this website - http://www.mnot.net/cache_docs/ – roshan lal Apr 07 '13 at 05:05