A2: 2017 – Broken authentication and session management (Part 1)

 Let’s move on and look at the next vulnerabilities class, the one with a silver medal. This is A2:2017 – «Broken Authentication and Session Management».

This vulnerability occurs when the user chooses a very strong password, passes it through a secure channel, and accesses only the appropriate area of a website, but it is for nothing, because website logic is broken, and a user session can be intercepted after successful authentication.

Wait, how?
To understand why this happens, you need to dive into the theory and remember how our interaction with web applications occurs. As you know, the key protocol here is HTTP, which is a stateless one. This means, that after sending or receiving any data, a server and a user forget each other forever. Unlike, for example, TCP where the communication session is established first and only after that the data is exchanged.
You might say that this makes no sense – I enter my login and password and only then I can upload a photo of me and my friends to Instagram. Isn’t it an establishment of a session? The server determines somehow that I have permission to do it!
That’s right but your credentials don’t handled by HTTP protocol. Web server and web application logic does this for you.

Sessions and Cookies
Session is nothing but and user’s activity tracked by the server. When you enter your login and password server creates a session of this connection with a unique identifier (number or token), also called Session ID. This information is stored on the server but not on the client. Client part of this process is called Сookies. Session IDs and Сookies allow you to skip passwords each time, remembering what’s in your shopping cart, and so on. When a user logs out the Session ID is destroyed on the server, and cookies are removed from the browser cache.

Authentication
In general, the authentication looks like this:

1. The user enters his or her credentials into some form.
2. The server verifies these credentials and creates a session that is stored in its database.
3. Cookies with the data of this session are put in the browser cache.

Now every time you request data from server cookies are checked. If data in cookies is not correct or obsolete, the request is ignored.

Oh, man, I love cookies. But we’re going to steal some in the next article.

This time we have another related thing to deal with. In OWASP Mutillidae II we have a dedicated section called «Broken Authentication and Session Management» and we’re going to check the first example  «Authentication Bypass» > «Via Bruteforce».
Here is a familiar form:

And we could use our trusty sqlmap, but let’s use ZAP Proxy again to crack a password. There’s a tool called thc-hydra, but here in ZAP there’s a dedicated tool for HTTP passwords. Let’s turn on local proxy first:

Now we login as our friend Fred. We do not know the password, so we introduce random characters. Proxy intercepted our session and we can see all the necessary information:

Here in ZAP we can design our password cracking logic directly from ZAP GUI. That’s way easier than thc-hydra. Just right-click on the part of a request and select «Fuzz».

Now we specify the dictionary and that’s it. In fact, ZAP comes with a set of dictionaries for various scenarios. For example, we can use one of them to exploit a SQL flaw just like with sqlmap. Because in the end, it’s all the same – we’re sending some data to form and then analyze the reaction. So, let’s run the fuzzer:

Wow, that was fast. ZAP guessed the password for our old buddy Fred and it turns out just «1». Fred, what’s wrong with you? We can experiment with other forms, for example, with those that we have been doing here, and pick up appropriate payload to detect vulnerabilities.

What can we do about it?
Recommendations are fairy standard – make your passwords strong and long or use multi-factor authentication, don’t leave default passwords, and limit delay for failed login attempts.