> > However, someone made a claim to me recently that some > information stored as a session attribute could be alterred > directly by the user, client side, and therefore posed a > security risk to a particular application.
I can constract a scenario where that could be true... Say a web app is based on Perl CGI, the Server process is not persistent, so the idea of a session is via a client cookie. Many developers used to add additional info to that cookie, perhaps to save a DB lookup on each following request. Normally, a non-persistent cookie would be used which keeps data in memory. Although technically, that data is editable client side, it would take a fair bit of work to modify browser memory. Of course, if the client is a script/program you wrote, then it's trivial to modify. Some folks would use a persistent cookie for this data... so when a user returns to a website at a later date, it might remember them. That type of cookie is trivial for even an enduser to modify (it's a plaintext file). Bottom line - if the server is trusting the values in the cookie and "ACCESS_LEVEL=5" changes to "=9", there is a security issue. I once had the pleasure of embarassing an Ecommerce company's training instructor during a class when I'd asked about cookies/sessions/security. He'd flippantly said, "We are totally secure," but then had a puzzled look on his face when I asked him why then his current shopping cart had gained 1000 items without him doing anything? (I borrowed his cart sessionID from the URL and made the change locally. They dismissed that because there would be "no way for a normal user" to steal someone elses sessionID... so later, I wrote down the sessionID's from three employees sitting in cubes outside the conf room who'd left with their screens unlocked. Tisk Tisk.) But I digress... Java session attribs are stored in server-side memory because servlets have the benefit of persistent running processes. They should be secure from most client side trickery. But if a developer chooses to muck with cookies manually and put sensitive data in them, all bets are off. ;-) Maybe the friend is thinking about the way some poorly written Perl sessions could be hacked. Or maybe they think the sessionID is a sequential number... and figure they could create their own session, then just increment by one to latch on to another users session. Manually created sessionID's might do something stupid like that, but J2EE jsessionid's are smarter. Although I must admit, I've never looked at the code to see how Tomcat creates them... I'm betting a one-way hash based on IP, system millis, random thingy, and foo. Hope that helps, Timo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
