Web applications are those that are accessed using web browsers like Firefox or Internet Explorer. The protocol used by web applications is called Hyper Text Transfer Protocol (HTTP). The secure version of this protocol is HTTPS.
These protocols are stateless. For eg. When you fill in your username and password on gmail, the data you enter is sent to login program on the gmail server. The login program checks whether you sent valid credentials and either shows you your inbox or tells you that data you entered was invalid. This request-response set is one ‘transaction’ in HTTP.
If you now click on any link in the inbox, the request sent to the gmail server is a ‘fresh’ one, at the level of HTTP, with no connection to any previous requests that you sent to gmail. So, web applications have to handle the aspect of a ‘session’ on their own.
Typically, when a user authenticates himself to a web application, the web application provides the user with a token. The server also makes note of the fact that token A was given to user Ram. Any request that Ram now makes is accompanied by the token A. The server also expects any request from Ram to be accompanied by the token A. When Ram logs out, the server destroys the token.
This is the essence of session management in web applications.
Secure web applications should satisfy the following criteria:
– Session tokens should be large enough and random enough.
– During authentication a new session token should be provided to the user.
– When the server receives a request for a page within an authenticated area, it should always check for the presence of an appropriate session token.
– During logout, the session token should be destroyed on the client side.
– Session tokens should not be reused by web applications.
– Based on the criticality of the web application, session time out may be implemented.
Some common attacks related to session management:
– Authentication bypass: When there is a request for a page within a restricted area that is not accompanied by an appropriate authenticated session token and the web application serves the page to the client, an authentication bypass can happen.
– Session Fixation: When the same session token is used before and after authentication, a session fixation attack can occur
– Improper logout: When the logout program does not destroy the session token, pages within a restricted area can be viewed an unauthorized user.
– Cross Site Request Forgery: This is a slightly complicated kind of attack which requires the user to be logged in during the attack.
Comments are closed.