Challenge 1 – Sign Up

The sign up pages are pretty common in web apps. The basic functionality of these pages is simple.

• Users enter their email address and some other details

• If the email address is not already in the database, the app will create a new account

• If the email address already exists in the database, the app will show an error

Let us visualize the happy path with the help of a sequence diagram:

That is the happy path for one user creating an account.

Next, let us reimagine the same scenario, but with two changes:

1. Two users are trying to create user accounts at the same time

2. Both users are trying to sign up with the same email address

The steps at a high level are:

1. Users fill out the Sign up form

2. Both users click on Sign Up at the same time

3. The app will create two threads

4. The threads will each check if the email exists in the database

5. Both threads will get an email does not exist response from the database

6. The app will proceed with account creation

7. Two accounts will be created by the app

8. Both accounts will have the same email address

Well, this looks good in theory, but is it practical? Let us find out.

Before getting started with following steps, navigate to Admin > Reset Database page (webapp/admin/reset-database.php)

First, let's go through a regular flow:

1. Open your browser

2. Navigate to the Sign Up page

3. Click on the first user button - this will fill the form with details of the user Tom

4. Click on the Submit button

We have created a user account on the system now. We need to see if the app allows us to sign up for another account with the same email. Let us test that by repeating the same steps.

Uh oh! The application does not permit this account creation. However, some time has passed since you created the first account.

We need a way to speed up the sign-up process. We want both the requests to happen more or less at the same time. But how can we do that?

Browser dev tools can be used to send multiple parallel requests to the application in a single go. We can explore that path later. For now, we need another method.

Instead of speeding up the process on our end, we can slow down the app. In real life, attackers achieve this in two ways:

1. By launching distributed denial of service attacks against their target OR

2. By launching their attacks during peak traffic periods

Thankfully, we do not have to do that. TimeGap theory will do that for us.

1. On your browser, navigate to the Settings page of OWASP TimeGap Theory

2. Change the Main wait to 5 seconds

3. Click on the Update button

This will make TimeGap Theory wait 5 seconds before every modification operation. If you try to perform anything that requires writing to the database, you will see that it's loading slowly.

5 seconds is more than enough time for us to try out the attack scenario. We need to fire two sign-up flows within 5 seconds time and that requires some preparation.

Preparation Phase

1. Open two browsers side by side (Use private/incognito window if you do not have two browsers)

2. On both the browsers:

   1. Navigate to the Sign up page

   2. Click on the second user button this time - this will fill the form with details of the user Jerry

Alright, the preparation is done. Here comes the exploitation phase.

Exploitation Phase

1. Click on the Submit button on the first browser

2. In the second browser, click the Submit button within the five seconds window

Post-exploitation phase

1. Wait for both the browsers to complete the request

2. You should see both browsers complete the requests without any errors

3. On one of the browsers, navigate to the Manage Users page

4. Boom! You should have two user accounts with the same email address

5. If you check your score, you should also see you now have 100 points

6. Before moving on, revert the delay back to 0 on the Settings page

Yes, we hear you. This attack technique is not realistic. There is no way you can ask web apps to act slowly in the real world. Launching a distributed denial of service attack is also not reliable. So, what can you do in the real world? If you can’t slow down the target, you need to speed up. No, we do not mean clicking on multiple browsers at the same time. You need to automate this part.

Browser Dev Tools

We love browser dev tools. They are useful for performing some quick security tests. These quick tests include TOC/TOU as well. 4

First, we need a valid fetch request:

1. Open your browser (Chrome or Firefox)

2. Navigate to the Sign up page

3. Click on any of the user button

4. Open up dev tools by pressing F12 on the browser

   1. On Windows, you can use Ctrl + Shift + I

   2. On Mac, you can use Cmd + Shift + I

5. On the Sign up page, click on the Sign Up button

6. On the browser dev tools, click on the Network tab

7. Right-click on the sign-up.php request

8. Click on Copy > Copy as fetch

Paste this in the Console tab of the browser dev tools. It should look like the following:

You may see a slightly bigger fetch request. This is because of the additional headers and request parameters added by the browser. These are optional. The above example shows the bare minimum fetch request.

But that’s just one request.

We need two parallel fetch requests.

This can be done by copying and pasting the fetch request without pressing the Enter key.

Before running this new command, we need to clear the slate. It involves three simple steps:

1. Ensure that there is no delay

   1. Go to TimeGap Theory > Settings

   2. Check that Main wait is set to 0

2. Delete any existing Tom user

   1. Go to TimeGap Theory > Admin > Manage Users

   2. Delete the user Tom

3. Clear your current score

   1. Go to TimeGap Theory > Score

   2. Click on the Clear button

Alright, our slate is clear. Let us execute the attack now:

1. Enter the combined fetch requests on the Console tab of browser dev tools

2. Press the Enter key

3. Go to TimeGap Theory > Admin > Manage Users

4. See if two users with the same email address are created

5. Go to TimeGap Theory > Score

6. Check if you got points for completing the Sign Up challenge

What would be the business impact of such an attack? Depending on how the app is designed, there are several possibilities:

• A legitimate user may try to register for their account in the future

• They may also get several emails asking them to confirm the account creation

• If a legitimate user confirms the account, the attacker may get a permanent backdoor to the user account

• Attackers would be able to carry out any actions on the app with all the audit trails pointing out to the legitimate user

Let’s summarize what we completed:

1. The Sign up page allows only one user account per email address

2. You ensured the business logic is working under normal scenarios

3. You slowed down the system and bypassed the business logic

4. You bypassed the business logic by using a tool that makes concurrent requests

5. Now you know how TOC/TOU security issues work and how to exploit them