Challenge 1 – Sign Up
Sign up for an account using this page. Only one account per email ID is allowed.
Last updated
Sign up for an account using this page. Only one account per email ID is allowed.
Last updated
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:
Two users are trying to create user accounts at the same time
Both users are trying to sign up with the same email address
The steps at a high level are:
Users fill out the Sign up form
Both users click on Sign Up at the same time
The app will create two threads
The threads will each check if the email exists in the database
Both threads will get an email does not exist response from the database
The app will proceed with account creation
Two accounts will be created by the app
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:
Open your browser
Navigate to the Sign Up page
Click on the first user button - this will fill the form with details of the user Tom
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:
By launching distributed denial of service attacks against their target OR
By launching their attacks during peak traffic periods
Thankfully, we do not have to do that. TimeGap theory will do that for us.
On your browser, navigate to the Settings page of OWASP TimeGap Theory
Change the Main wait to 5 seconds
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
Open two browsers side by side (Use private/incognito window if you do not have two browsers)
On both the browsers:
Navigate to the Sign up page
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
Click on the Submit button on the first browser
In the second browser, click the Submit button within the five seconds window
Post-exploitation phase
Wait for both the browsers to complete the request
You should see both browsers complete the requests without any errors
On one of the browsers, navigate to the Manage Users page
Boom! You should have two user accounts with the same email address
If you check your score, you should also see you now have 100 points
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:
Open your browser (Chrome or Firefox)
Navigate to the Sign up page
Click on any of the user button
Open up dev tools by pressing F12 on the browser
On Windows, you can use Ctrl + Shift + I
On Mac, you can use Cmd + Shift + I
On the Sign up page, click on the Sign Up button
On the browser dev tools, click on the Network tab
Right-click on the sign-up.php request
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:
Ensure that there is no delay
Go to TimeGap Theory > Settings
Check that Main wait is set to 0
Delete any existing Tom user
Go to TimeGap Theory > Admin > Manage Users
Delete the user Tom
Clear your current score
Go to TimeGap Theory > Score
Click on the Clear button
Alright, our slate is clear. Let us execute the attack now:
Enter the combined fetch requests on the Console tab of browser dev tools
Press the Enter key
Go to TimeGap Theory > Admin > Manage Users
See if two users with the same email address are created
Go to TimeGap Theory > Score
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:
The Sign up page allows only one user account per email address
You ensured the business logic is working under normal scenarios
You slowed down the system and bypassed the business logic
You bypassed the business logic by using a tool that makes concurrent requests
Now you know how TOC/TOU security issues work and how to exploit them