Archive for the 'Java' Category

Java, Security

Generate new session ID in Java EE?

Is there a Java EE equivalent to PHP’s session_regenerate_id()? I’d expect to find it in the neighborhood of HttpSession but don’t.

I like to change the session token whenever there’s a change in a user’s privileges. For example, let’s say that Suzy is surfing a site anonymously for a while before she logs in. As an anonymous user, she has pretty low privileges. Then when she logs in, she has greater privileges on the system. Maybe she can view her home address, update billing info, or heck: maybe she has administrative access. There has been a change in access level.

A problem arises when while surfing anonymously with low-level access, Suzy’s session ID is stolen by an attacker using cross-site scripting or session fixation. After Suzy logs in, the attacker now has the same increased privileges on the system that Suzy does, because the attacker has Suzy’s session ID.

One countermeasure to session fixation attacks is to change Suzy’s session ID whenever her privileges change. When she logs in, assign her a new session ID. When she logs out, assign her a new session ID. Each time Suzy gets a new session ID, the old session is invalidated and the attacker — who has the old session ID — is left with an useless (nonexistent) session.

PHP’s session_regenerate_id() does this transparently, copying over session data to the new session each time (although the implementation is not without its problems). The truly crazy can even do this on each request. If I’m not mistaken, ASP.NET 2.0 also offers a means to generate a new session ID, though maybe only with cookie-less sessions. Java EE does not appear to at all. Maybe some servlet containers do, but it’s not in the spec so far as I can see.

Yes, I can always create a new session and copy over all the attributes to the new session before invalidating the old one. No, it isn’t that hard. I’m just wondering if there isn’t a way for the container to do this instead. Anyone know?


It’s not always a good fit.

“So,” Tim asked, “still down on Java?”

When we had last spoken, I was reading Beyond Java, so that was an understandable question. I’ve had the conversation an awful lot lately and people keep being surprised by whatI say, so I figure it’s about time I write something here to explain my position.

Am I down on Java? Not per se. Java is not a language I generally enjoy working with, but I write web apps for a living. I do not believe that Java is an ideal choice for the work I do — I don’t even think it’s a good one. There are rays of hope: RIFE looks to be especially promising (hell, even exciting!) for making Java web apps far less painful than the norm. But by and large, the way I believe most people write Java web apps makes it a very unpleasant platform to work with. Unpleasant in the sense of slow and ineffective, with far too much code.

I’ve also been turned off by unbearably slow development cycles, which I cannot lay entirely at Java’s feet. Other factors like politics and methodology contribute. Still, in most people’s hands it takes longer to write something in Java, becaCan a team of experienced, solid developers work fast and well with Java? Of course. But most development teams are not filled with that kind of programmer.

If it works for you, great. I don’t think it’s worth anyone’s while to get into pointless language debates. But personally, I would rather use something other than Java for web apps, especially the whole JEE stack. My experience with J2EE has been barely manageable complexity in both development and operations management, which stands a good chance of making apps more difficult to maintain and secure. It is a good fit for some applications, when JEE serves to address and alleviate complexity in the problem space by providing simple solutions. Assuming that happens. :) I just don’t see web app control flow and presentation as being a hugely complex problem until Java enters the picture.

So what’s the alternative? Oh, there are plenty. Could or should Java play a role in our development? Of course. There’s often a reluctance to involve more than one language in an application stack to keep things “simple,” which I think is short-sighted. I often like to use more than one language for complex apps because it forces me to keep the design and APIs clean, a collection of loosely coupled services. Sometimes I like to use a full-stack framework, too. It depends. Use the best tools for the job. Leverage the strengths of the languages in your arsenal. Java fits well on the far back end, integrating legacy systems and managing interplanetary navigation. Closer to the front end of a web app, I’d use something a bit more suited to web development, like PHP. In the end, I think it would be faster to develop, easier and cheaper to maintain, and make developers happier. I try to be pragmatic and happy in my work.

« Prev