Broken Authentication and Session Management, Part Ⅰ
Broken Authentication and Session Management, Part Ⅰ
In this article, we go over a few simple ways that hackers can exploit vulnerabilities in a browser to gain access to client or user data.
Join the DZone community and get the full member experience.Join For Free
Learning by doing is more effective than learning by watching - that’s why Codebashing offers a hands-on interactive training platform in 10 major programming languages. Learn more about AppSec training for enterprise developers.
OWASP defines Broken Authentication and Session Management as: ‘Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.’ In other words, an attacker can get unauthorized access to a user's data due to flaws in the implementation. Before exploiting this vulnerability you need to know a few concepts:
- What a Session is and why we need a Session.
- What a Cookie is.
- What Authentication is.
As you know, applications work on HTTP protocol which is a stateless protocol, meaning it cannot retain the user activity. In other words, a server cannot retain a memory of the identity/activity of each client (user) that connects to a web site. For example, when you log in to Facebook and change your profile picture, you need to enter your credentials for all the requests being sent to the server since the server doesn’t know who you are. So the question is, how does a server track user activity? Users cannot enter their credentials for the requests. Here's where sessions come into play.
A session is nothing but a server side storage of users' information to persist the activity with the web site. Usually, all the servers generate a session for that connection with unique session token which is known as a session ID. Do make a note, session values should be stored on the server side but not the client side. For example, whenever you log in to a website, the server will store your information in your system as a cookie. These cookies will help with authentication. Since the server generated a session ID for the user, the client doesn’t need to provide their information on each subsequent request. The client (browser) usually stores and sends the token as a cookie to the server. When the user clicks on the Logout link, the cookie with the session ID will be deleted and the server will terminate the user’s activity.
Authentication is a security process that ensures and confirms a user’s identity, typically in the form of Username/Password verification performed by the server. Typically the process of authentication would be:
- The user enters their login credentials.
- The server verifies the credentials of the user and creates a session which is then stored in a database.
- A cookie with the session ID is placed in the user's browser.
- On every subsequent request, the session ID is verified against the value from database to process the request. If the ID on the client varies from the ID in the database then request will not be processed.
- Once a user logs out of the app, the session is destroyed on both the client and the server.
Now, let's exploit this vulnerability with a practical example. Just fire up your bWAPP server (test server) and select 'Broken Auth. – Insecure Login Forms.' This bug could be silly or severe, but to find it one must sift through the page source to find sensitive information. So, when you view the page source (right click on the page and select view page source), you should see the user credentials stored in the HTML. This allows hackers to gain authentication with ease. In general, we sift through the HTML comments and hidden fields, I would say that’s a good practice.
Now we will see another code level flaw, select ‘Session Mgmt. – Administrative Portals’ and set the security level to 'low.' If you notice the URL ‘/bWAPP/smgmt_admin_portal.php?admin=0’, there’s a string appended after the ‘?’with a value '0,' which means the session ID was passed in the query string where anyone could see and manipulate the values. Let’s change the value from ‘0’ to ‘1.’
So one can simply brute force the URL with different IDs. Also, look at the bug ‘Session Mgmt. – Session ID in URL.’
Now, set the security level to 'medium' in the Administrative Portals page and refresh the page. If you notice the URL, there’s no query string with ‘admin.’ So, was that bug fixed? No, as a security analyst you should always look for numerous ways to find the flaw. Why don’t you check the cookies (press F12) and try modifying them? Fire up Owasp ZAP/Burp suite/ Fiddler to capture the request and compose a new request by modifying the ‘admin’ cookie. Here I am using Fiddler. Capture the request and replay it using Composer. Change the value ‘0’ to ‘1.’
The other most common vulnerability is incorrect logout management. Select the bug, ‘Broken Auth. – Logout Management’ and click on the ‘here’ link displayed on the page
Once you click on ‘Yes’ you will be redirected to the login page. But the session is still alive. Just click on the back button and you will be redirected to the /bWAPP/ba_logout.php page. Hence, an attacker can easily perform a session fixation attack. We will learn about Session Fixation in another post in greater detail.
So we’ve learned that Broken Authentication and Session Management involves all kinds of flaws that are caused by errors in the implementation of authentication and/or session management.
How to Find This Vulnerability
Secure code reviews and penetration testing can be used to diagnose authentication and session management problems. We must carefully review each aspect of the authentication mechanism to ensure that the user’s credentials are protected at all times. Though we haven’t covered Forgot/Change password features, one must double check the implementations for those mechanisms as well.
Published at DZone with permission of Hari Charan . See the original article here.
Opinions expressed by DZone contributors are their own.