Application security encompasses measures taken throughout the application's life-cycle to prevent exceptions in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance of the application.

Friday, December 30, 2011

Broken Authentication and Session Managemnet

HTTP communication uses different TCP connections which is stateless protocol, so web server needs some to recognize every user's connections. Session token is one of the method, which the web server sends to the client browser after successful client authentication. Session token is nothing but a string of variable size which can be used in different ways, like as cookie in HTTP header, or in the URL, or in the body of the HTTP  request.
 
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit implementation flaws to assume other users’ identities. If session management is not properly handled by the developer in the application then this will introduce several session related vulnerabilities to the application like
 
• Session Fixation
• Session Hijacking
• Session Prediction

Session Fixation is a type of attack where the attacker take an advantages of limitation in the way the web application manages the session ID. I discovered this vulnerability in many applications during my regular projects. Usually this will comes into picture if your application does not assign a new session ID, and making it possible to use an existent session ID after the user login to the application. For which it is possible to fix the session ID for a particular user and once the user (victim) login to the application it is possible for the attacker to login to the application using the same session ID.




Let’s take one scenario where some application DEMOAPP is vulnerable for this Session Fixation. Let’s assume the URL of the application is www.demoapp.com. So first the attacker will browse the application and the application will provide a session ID to the attacker. Then the attacker will construct a URL like http://www.demoapp.com/login.jsp?jsessionid=abcd
, and send it to the user (victim) over instant messenger or by any other means. Then the victim will click on the URL and the login page will appear. Once the victim will login to the application then the attacker is also able to access the application having same rights as the victim.

So to fix this issue, it is recommended that the application must assign new session ID after authentication process is complete.
That means the session ID for the user must change before and after authentication process. 

Session Hijacking is a type of attack where the attacker will exploit the session control mechanism in order to manage the session token of the web application and will take control over other legitimate users session.

In session hijacking the attacker steal the valid session token of authorized application user and gain unauthorized access of application. The session token could be compromised in different ways:
 

Session sniffing/man in the middle attack: In this attack the attacker will use sniffing tools like wireshark, cain & abel, ettercap to capture valid session token and then use the same session token to gain unauthorized access of the application.

Client-side attack like XSS: In this attack the attacker sends a crafted link to the victim with the malicious javascript, when the victim clicks the link, the javascript will run and complete the instructions created by the attacker.

Session Prediction attack focuses on predicting session ID values to bypass the authentication schema of an application. By analyzing and understanding the session ID generation process, an attacker can predict a valid session ID value and get access to the application.

The attacker needs to collect some valid session ID values of authenticated users. Then he has to an analysis to understand the pattern of session ID, and the information that is used to create it, and the encryption or hash algorithm used by application to protect it. Some bad implementations use sessions IDs composed by username or other predictable information, like timestamp or client IP address. In the worst case, this information is used in clear text or coded using some weak algorithm like base64 encoding.
 

No comments:

Post a Comment