3

I'm planning to send a user's session ID as a URL parameter which will be AES encrypted. I don't think my app has any link sharing problems. Is this idea feasible? Is it safe?

1
  • 2
    If your session ID is cryptographically random, as you mention, what's the point of encrypting it? What attack are you trying to prevent? If someone gets a copy of the AES-encrypted ID, and can use it directly in a URL, how does that help prevent the attack you're thinking of? May 10, 2013 at 18:59

3 Answers 3

3

If your session ID is truly random, there is no additional security in AES-encrypting it. If, however, it is not random, I would strongly recommend against doing so, for reasons similar to why no-one sane uses predictable session ID tokens.

Also, if you're not using SSL, your traffic can be sniffed. This means that, no matter how much you encrypt the token... it is still plainly visible. (Well, your traffic can be sniffed with SSL on, but it's a bit more complicated)

3
  • Sanity being relative and all, lots of sane people use predictable session IDs.
    – Steve
    May 10, 2013 at 18:14
  • thanks for the comment , well appreciated and my session id is random using securerandom class
    – Roshan
    May 10, 2013 at 18:18
  • 1
    @SteveS: I have rarely seen predictable session IDs. By predictable, I mean a form that does not require a table lookup to find the userdata back. Should have been more accurate. May 10, 2013 at 18:24
3

It's a bad idea.

Encrypting the session identifier has no real impact on the security of your application. If the traffic is sent in plaintext (without SSL) anyone is able to read that encrypted session ID and then use it to impersonate the legitimate user.

Let's say my session ID is 12345. Every time I want to go to your house you ask me about my session ID, I'm gonna yell it from behind the door and someone might overhear it. To solve the problem, we encrypt the session ID, so it becomes OF&HN7907fynNYH. That changes nothing, someone will still overhear it and is able to repeat it.

As for the other part of your question, about putting the session ID in the URL. The reason I think it's a bad idea because the URL can be used and stored in so many other places; in proxy logs, can be bookmarked, or stored in error reports. This subject has been discussed before here.

2

Is it feasible? Yes. It's a standard pattern for cookie-less session and was a de rigueur pattern for session management in JSP app for a number of years.

Is is a good idea? No, for a couple of reasons.

  1. One of the primary vulnerabilities for a site that has a concept of session management is session hijacking, where the session id is sniffed and stolen, as Sébastien mentioned. The URL is the most vulnerable location that could possibly be chosen for this identifier. It's visible in the browser, on the wire (if not using SSL) can be bookmarked and easily shared.

  2. It can impede usability. This is not a security issue, but if the parameter is embedded in the URL, as JSP ids often were, it can prevent legitimate sharing and bookmarking, and lead to user frustration when they try to return to a bookmarked page once a session has expired, only to have the application tell them that the URL is invalid, and they have no idea how to get back to the page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.