1

HTTP is a stateless protocol. However, when the user logs into a web application, he likes that some session information be preserved, such that he does not have to login again when he wants to go back and forth between web pages of the same application.

Associated to each session is a lifespan. Moreover, some sessions are "transient," meaning that they are closed as soon as the user closes the web page (even if the session is not yet timed out).

Many application servers provide the notion of session. For instance, the documentations of WebLogic (which we are currently working with) discusses "Using Sessions and Session Persistence" (See Chapter 10 of Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server 11g Release 1).

The question is:

Given the variety of possible attacks on sessions (session hijacking, session fixation, etc.), is it enough to rely on the session management features of the application server? In other words, can the application be "session agnostic," and everything be handled by proper configuration of the application server? (One can also assume that connections are over a properly implemented HTTPS connection.)

I believe the answer is NO, but I need a concrete justification as to what we can and what we can't expect from the application server.

Pointing to best practices and possible threats/attacks on session management is highly appreciated.

Edit (concerning Andrew's comment): In your response, please assume that everything else (firewall, file-system, database, etc.) is configured correctly. Now, can application server be configured in such a way that the application itself need not manage sessions? That is, can we write a totally "session agnostic" application, and put it in an environment which (by proper use of application server, firewall, etc.) prevents session hijacking, session fixation, and other session-related attacks?

Improve this question
2
  • What management? You need multiple layers of security on this session, which is from the network firewall up to the crypted and randomized token, and in between there is injection and code execution isolation. For example, you need to prevent one user from reading another user cookie and session data even in case he has SQL and PHP shell on the website. There isnt any such functionality built into the servers, it needs to be designed, implemented and tested for specific requirements by chaining security from firewall, thru filesystem ACL, SQL ACL and so on.
    – Andrew Smith
    Jul 25, 2012 at 13:07
  • @AndrewSmith: Thanks for the prompt reply. I think the question is a bit vague. I'll edit it to be more clear.
    – Sadeq Dousti
    Jul 25, 2012 at 14:44

2 Answers 2

Reset to default
4

No. It is not enough to just use the application framework's session management features and do nothing more. It is definitely a good idea to use the application framework's session management (do not roll your own session management) -- but you will need to take some additional steps as well.

The exact division of responsibility between the developer and the session management layer will depend upon the particular session management layer, but here are some issues that are typically the responsibility of the developer and are not handled by the session management layer:

  • You must implement or enable CSRF defense (CSRF tokens). Normally the session management layer will not do this for you.

  • If you want to use https, you should set the secure attribute on all cookies. If you are using https sitewide, it is your responsibility to enable HSTS.

  • You should configure the session management layer so it will not accept session ID's in a GET parameter. This is important, to avoid session fixation vulnerabilities.

  • You will likely need to tell the system to generate a new CSRF token immediately after logging in, to defend against login CSRF.

  • If you want to use the HTTPOnly cookie attribute, it is your responsibility to set it. It is debateable whether this cookie attribute provides any measurable increase in security against a sophisticated attacker, but some people recommend it as a "can't hurt" security practice.

I recommend reading the resources that OWASP makes available. This will help you understand what you need to do to secure your web application.

Improve this answer
2

In general, the most fatal mistake you can make when developing an application is attempting to "roll your own", when such functionally is already provided by your platform (like trying to re-implement ssl). Vulnerabilities are inevitable, by relying on your platform you are gaining the strength of the community to audit your security for FREE, the maintainer of your platform will then patch your system for FREE.

That being said, there are some attacks to be aware of. It maybe that by default your session handler isn't as strong as it could be. You will want to enable both the "secure" cookie and HTTPOnly cookie attributes. The "secure" cookie attribute forces the cookie to be transmitted over https, which is a good way of handling potential owasp a9 violations. Another pitfall that you should be aware of is that all session id's should only be transmitted as a cookie and not as a GET variable. Transmitting your session id as a GET variable opens the door for session fixation.

Also be aware of CSRF other wise known as "Session Riding", but this attack is something you have to defend against and it is not the responsibility of your session handler.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .