0

In the organization that i work for, there was a serious debate about the following.

Scenario:

There is a POJO with 6 different properties all are of type Strings. These values need to be persisted as cookies so that it can be picked back when someone does a booking on the site. These values in POJO signify the referer who drove the customer to the site. Before shoving it into the cookies, It is converted into json format and stored in cookie. While retrieving it is retrieved and deserialized into a POJO. I don't see any big issue with this, but others seem to be against it and being a quick managerial meeting, i could not ask why do you think that it is bad? Is this really bad, if so why?

Additional Note:

There are checks to make sure it is a valid value and it is base64 encoded before being stored in cookie. So from security perspective, there are no concerns as such even if someone hacks.

minion
  • 4,313
  • 2
  • 20
  • 35
  • Is it being stored ONLY in a cookie? If thats the case you lose any ability to do metrics on the data. Why not store a reference to a row in the database – dstarh Jun 22 '15 at 14:59

1 Answers1

1

I guess the answer depends on your answer to these questions:

  1. Since you can never trust ANYTHING that comes in a client request, are there any harmful effects that could come by a hacker spoofing the pojo value?

  2. By sending the object to the client, does this expose any internal implementation details that should never be seen by a hacker?

  3. Is there a mechanism in place that will allow the POJO object to change "shape" (ie add new properties) such that an old POJO sent from a client won't break the application when it is deserialized into a newer application version?

  4. Can you guarantee that the value won't exceed the maximum cookie size

If these questions don't raise any issues then I don't see an issue in maintaining user specific values in a cookie

Community
  • 1
  • 1
lance-java
  • 25,497
  • 4
  • 59
  • 101
  • There are checks to make sure it is a valid value and i forgot to add to OP it is base64 encoded before being stored in cookie. So from security perspective, there are no concerns as such. – minion Jun 22 '15 at 15:04
  • 2
    I don't see how base64 encoding helps make the system any more secure - it's encoding, not encryption. What checks are being performed to make sure it's a "valid" value? What are the consequences of someone modifying the string properties? – Joseph Redfern Jun 22 '15 at 15:10
  • Agreed, it is just encoding and not encrytion. Not significant if someone modifies the cookie. There are checks and balances at the backend. – minion Jun 22 '15 at 15:11
  • Hmm. If you're able to confirm that the cookie is valid (i.e. you're keeping track of state server-side), when why can't you just use a session and let the server keep track of the java object? – Joseph Redfern Jun 22 '15 at 15:19
  • Functionality is across sessions. Even if user comes back tomorrow, we should attribute to the referrer. It was talked as if it is a felony which surprised me. – minion Jun 22 '15 at 15:22
  • 5. (possibly) In certain countries/continents/unions such a cookie might be seen as a "tracking cookie" and you need to ask permission of the user before your site is even allowed to create such a cookie. – Gimby Jun 22 '15 at 15:45