views:

1017

answers:

4

i'm hearing that some people believe storing info on the server in a session is a bad idea, that its not secure. as a result, in a multi-page business process function, the application is writing data to a db, then retrieving the info when its needed. is there something necessarily unsafe about storing private info in a session?

A: 

Not that I know of - as long as your web server process is secure. However, it makes scaling out a real bitch.

TheSoftwareJedi
+4  A: 

HTTP sessions themselves aren't inherently unsafe. However, depending on your application server / container, the mechanism in which session cookies are passed back to the browser (and lack of transport layer security - SSL) can allow malicious parties to perform a variety of attacks (cross-site scripting, session hijacking, etc.). I would spend some time researching these things along with SQL injection to understand the full ramifications of using HTTP sessions. If your application runs within a firewall, there are often much bigger security risks than this one, such as social engineering.

jonathan.cone
+4  A: 

There's not a security risk in storing attributes in a Session, as long as the session itself is safe from hijacking.

There are some serious issues involving concurrency and sessions. Since its extremely common for multiple threads to be making requests concurrently for a single session, you have to make sure that the objects you store in a Session are thread safe. Either make them immutable, or make them thread safe with memory barriers like synchronization. I highly recommend an article on the subject by Brian Goetz.

erickson
+1  A: 

As well as performance and concurrency issues, you should also think about usability. Do multiple open pages, the back button work, bookmarks, linking to your site, etc., work? I've ended up booking a flight on the wrong day on aerlingus.ie and almost booking the wrong hotel on lastminute.com because of their dismal web sites.

Tom Hawtin - tackline