Solved

J2EE session security and cookies

Posted on 2014-12-12
9
189 Views
Last Modified: 2014-12-16
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
0
Comment
Question by:dgrafx
  • 4
  • 3
  • 2
9 Comments
 
LVL 78

Assisted Solution

by:David Johnson, CD, MVP
David Johnson, CD, MVP earned 100 total points
ID: 40501898
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
 
LVL 25

Author Comment

by:dgrafx
ID: 40501899
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
 
LVL 78

Expert Comment

by:David Johnson, CD, MVP
ID: 40501920
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
 
LVL 25

Author Comment

by:dgrafx
ID: 40501931
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
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 35

Accepted Solution

by:
mccarl earned 400 total points
ID: 40501952
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
 
LVL 25

Author Comment

by:dgrafx
ID: 40502846
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
 
LVL 35

Assisted Solution

by:mccarl
mccarl earned 400 total points
ID: 40503947
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
 
LVL 25

Author Comment

by:dgrafx
ID: 40504037
Thanks guys - I needed a refresher course to get up to speed!
0
 
LVL 35

Expert Comment

by:mccarl
ID: 40504045
No worries, glad to help!
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

I spent nearly three days trying to figure out how incorporate OAuth in Coldfusion for the Eventful API. Hopefully, this article will allow Coldfusion Programmers to buzz through the API when they need to. Basically, what this script does is authori…
Introduction This article is the second of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers the basic installation and configuration of the test automation tools used by…
Explain concepts important to validation of email addresses with regular expressions. Applies to most languages/tools that uses regular expressions. Consider email address RFCs: Look at HTML5 form input element (with type=email) regex pattern: T…
This tutorial covers a practical example of lazy loading technique and early loading technique in a Singleton Design Pattern.

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now