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?