Secure Coding Compliance Assessment Session state must be managed

A new corporate p开发者_如何学Goolicy on Secure Coding was recently put into effect. The initial audit assessment tagged me deficient for:

Session state must be managed such that a session will withstand replay-attacks.

I'm not exactly sure what this statement means or why I am defecient in it. I'm developing a Java Web application and set a session as such:

session.setMaxInactiveInterval(36000);

Session state must be managed such that a session will withstand replay-attacks.

The statement is way too confusing. Rewording it would yield:

The session management framework must protect the application against replay of session IDs.

It is less confusing (hopefully), and continues to carry the same meaning as the former (again, hopefully).

Typically, if one were to implement a home-grown session management framework instead of relying on the one provided by the container for instance, then it is quite possible that the session management feature of the application would be susceptible to a replay attack.

A session replay attack would involve the scenario where the session ID is replayed back in a request, after the session has expired. A well written session management framework would recognize that the provided session ID is not a valid session ID. However, there have been instances where a vulnerable session management framework accepted the now-expired session ID, and recreated the contents of the session. In worser scenarios, the session management framework did not destroy the session at all, on session expiry, resulting in the scenario where a session ID replay resulting in requests being processed.

It must be remembered that even normal users of the application may unintentionally perform session-replay attacks, if they are able to browse to protected pages in the application without logging in. This is an indication of a failure in the authentication and the session management features of the application, for the app should ideally allow users to browse protected pages only after successful authentication, which would yield a token (a session ID) that may be used for a certain duration to access the site without further authentication. If you are using persistent cookies for authentication, you may have unintentionally introduced a hole.

Going by the above, one can protect any application from session replay attacks by:

• Ensure that you are using the container provided session management features. From the use of the session.setMaxInactiveInterval I would assume that you are it. But, to be sure, verify if you are creating session IDs using other means, or for that matter, verify if you are using identifiers that are equivalent to session IDs. In simpler words, ensure that your application relies only on the value of the JSESSIONID cookie (or the equivalent as configured in the container) to communicate session IDs to the browser. Also, verify if persistent cookie are in use (refer the above posted scenario).
• Invalidate the session after a certain idle period. If you do not invalidate the session, then an attacker has a larger time window to brute force the session ID. From the point of view of session-replay attacks, this is worse since the attacker can replay back a compromised session ID at any point in time, and still get access to a valid user session. You would also want to revisit the duration specified in the session.setMaxInactiveInterval for the value you are using currently is 10 hours. I would consider that to be insecure. Most applications do not require a rolling window of session expiry beyond 30 minutes, with 10 minutes being the value recommended for high-value apps.
• Destroy the server-side session and it's contents on expiry. In a servlet container, this is typically done by invoking session.invalidate() in a logout page/link. Ensure that you have provided users with a link to logout from the application in the first place, so that the logout request can be processed to invalidate the session using the before-mentioned API call. If you do not perform this activity, the server-side session object will be destroyed only on session expiry (which will occur after 10 hours of inactivity by the user; now you see why 10 hours is a bad idea).

this is to do with something similar to session hijacking.. where the auth token is held by a hacker to login at a later stage..

in my projects i've added a simple filter which does the following.

every jsp page which is responded would be given an attribute called id (the token is generated using UUID().. the same token is placed in the session..

when a page is posted, the filter (which is configured to filter all requests) checks for the equality of these tokens & proceeds only if the values match.

we also added a timestamp in the session & the database, whenever a page is submitted we check the time stamps in the session with the db.. if the number is within 10 ms then the request passes, else the user is redirected...