J2EE session security and cookies

OK - I rewrote this question ...

I need your opinion (based on facts) on security concerns of cookies used by J2EE sessions.

1. Are they written to disk?
2. Can they be read and or edited?

Thanks
LVL 25
dgrafxAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David Johnson, CD, MVPOwnerCommented:
Yes to both, they are saved to disk and editable. But the contents are not normally plain text.  There are many cookie editors out there. You can change the access to http only

Secure Cookie Protocol pdf
0
dgrafxAuthor Commented:
Thanks
What do you mean by change access to http only?

Also, can you post a link or two so I can research please.
What I'm looking for is best practice using J2EE sessions - what do others do to maintain security?
0
David Johnson, CD, MVPOwnerCommented:
httpOnly is supported as of Tomcat 5.5.28 and 6.0.19

The httpOnly functionality can be enabled for all webapps in
conf/context.xml:

<Context useHttpOnly="true">
...
</Context>

Open in new window

0
Introduction to R

R is considered the predominant language for data scientist and statisticians. Learn how to use R for your own data science projects.

dgrafxAuthor Commented:
ok - and what exactly does useHttpOnly do?
And what would you advise for older versions of CF?
And what about this issue on Railo?

I appreciate it!
0
mccarlIT Business Systems Analyst / Software DeveloperCommented:
what do others do to maintain security?
"Security" is a very broad topic. You would have to be more explicit about what you are referring to in the above question.

Maybe you need a quick (and dirty) overview of how sessions/cookies work...

Sensitive data (or other data aswell) is only ever kept on the server side. The servlet container (web server) stores that sensitive data locally on it's side and associates with a randomly generated ID. This ID has no inherent meaning, ie. outside of the server the ID is useless. This ID is sent from the server to the client in what you know as a cookie. All it is used for is so the client can subsequently send that ID in the cookie back to the server, so that the server knows who the request come from. The server can look up the data in its session based on the ID in the returned cookie, and it now knows that it is talking to you (rather than someone else).

The main security concerns around this, is that someone else may obtain this ID from the cookie and therefore can impersonate you. This can be gained from a couple of methods, either by directing "sniffing" the network traffic between the client and server, accidentally captured in intermediate internet device logs (when sent as part of the URL), retrieved from the client browser, etc. Firstly, this risk can be reduced by communicating via HTTPS, and secondly most session are reasonably short lived, and so once you log out (or after a short amount of time) the ID in the cookie becomes invalid and is totally useless to anyone.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
dgrafxAuthor Commented:
Thanks for the info guys.
To tell you what I'm referring to specifically - I'm doing a side gig (web development) for a company who is using client vars. I have asked why they are not using J2EE sessions to maintain state across servers. Their answer is that sessions are not secure.
So this is not my area of expertise but companies that I'm familiar with have always used J2EE sessions because they are "sticky". It's been a lot of years since I've seen client vars used to maintain state across servers.
So that is what prompted me to ask the question about how secure session vars are.
Where are J2EE session cookies stored?

And how secure are client vars I guess I should ask as well.
0
mccarlIT Business Systems Analyst / Software DeveloperCommented:
I'm not a CF developer so I can only give you info on what I have briefly read about client vars. Firstly, it seems that they is a number of choices in how client vars are implemented, either server-side in a database/registry or client-side in cookies. And this choice would have a major impact on how you talk about the security of them.

Client-side (or cookie based client vars) would be the least secure of the options, as it is possible for the details to be sniffed/intercepted as this information is sent from server to client (and back). Also, the client (or something running at the client machine) can modify the data at will.

Now server-side client vars and sessions would seem to be (from a security view) basically the same. I couldn't find anything definitive, but I guess that the client is tracked by a cookie (I'm guessing the CFID) and then the server looks up the (possibly) sensitive client var data from a database/registry based on that CFID. This is quite similar to sessions. The client is also tracked by a cookie (the JSESSION_ID cookie) and then the server looks up this id in its session storage to get the sensitive data. This session data is generally kept in the servers memory. NOTE that in both circumstances, it is NOT the data that is included in the cookie, but just an opaque identifier, and this identifier is used to look up the data on the server side. So in both cases, the data is NOT transmitted between the server and client.

So from what I can see there is no major difference, in terms of security, between client vars (server-side implementation) and sessions. The only difference is in their function, where client vars will persist its data for longer periods (it's configurable, but you probably talking weeks/months) where as sessions are more a temporary nature, storing data only for a single client session (typically minutes/hours).

I have asked why they are not using J2EE sessions to maintain state across servers. Their answer is that sessions are not secure.
I would challenge that and get them to explain WHY they believe this is the case.
0
dgrafxAuthor Commented:
Thanks guys - I needed a refresher course to get up to speed!
0
mccarlIT Business Systems Analyst / Software DeveloperCommented:
No worries, glad to help!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
ColdFusion Language

From novice to tech pro — start learning today.