To level set this recipe, let's first baseline the current number of records in the account table and perform SQL Injection to see this:
- Navigate to the User Info page: OWASP 2013 | A1 – Injection (SQL) | SQLi – Extract Data | User Info (SQL).
- At the username prompt, type in a SQL Injection payload to dump the entire account table contents. The payload is ' or 1=1-- <space> (tick or 1 equals 1 dash dash space). Then press the View Account Details button.
- Remember to include the space after the two dashes, since this is a MySQL database; otherwise, the payload will not work:
- When performed correctly, a message displays that there are 24 records found in the database for users. The data shown following the message reveals the usernames, passwords, and signature strings of all 24 accounts. Only two account details are shown here as a sample:
We confirmed 24 records currently exist in the accounts table of the database.
- Now, return to the login screen (click Login/Register from the top menu) and select the link Please register here.
- After clicking the Please register here link, you are presented with a registration form.
- Fill out the form to create a tester account. Type in the Username as tester, the Password as tester, and the Signature as This is a tester account:
- After clicking the Create Account button, you should receive a green banner confirming the account was created:
- Return to the User Info page: OWASP 2013| A1 – Injection (SQL) | SQLi – Extract Data | User Info (SQL).
- Perform the SQL Injection attack again and verify that you can now see 25 rows in the account table, instead of the previous count of 24:
- Switch to Burp's Proxy HTTP history tab and view the POST request that created the account for the tester.
- Studying this POST request shows the POST action (register.php) and the body data required to perform the action, in this case, username, password, confirm_password, and my_signature. Also notice there is no CSRF-token used. CSRF-tokens are placed within web forms to protect against the very attack we are about to perform. Let's proceed.
- Right-click the POST request and click on Send to Repeater:
- If you're using Burp Professional, right-click select Engagement tools | Generate CSRF PoC:
- Upon clicking this feature, a pop-up box generates the same form used on the registration page but without any CSRF token protection:
- If you are using Burp Community, you can easily recreate the CSRF PoC form by viewing the source code of the registration page:
- While viewing the page source, scroll down to the <form> tag section. For brevity, the form is recreated next. Insert attacker as a value for the username, password, and the signature. Copy the following HTML code and save it in a file entitled csrf.html:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://192.168.56.101/mutillidae/index.php?page=register.php" method="POST">
<input type="hidden" name="csrf-token" value="" />
<input type="hidden" name="username" value="attacker" />
<input type="hidden" name="password" value="attacker" />
<input type="hidden" name="confirm_password" value="attacker"
/> <input type="hidden" name="my_signature" value="attacker account" />
<input type="hidden" name="register-php-submit-button" value="Create Account" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
- Now, return to the login screen (click Login/Register from the top menu), and log in to the application, using the username ed and the password pentest.
- Open the location on your machine where you saved the csrf.html file. Drag the file into the browser where ed is authenticated. After you drag the file to this browser, csrf.html will appear as a separate tab in the same browser:
- For demonstration purposes, there is a Submit request button. However, in the wild, a JavaScript function would automatically execute the action of creating an account for the attacker. Click the Submit request button:
You should receive a confirmation that the attacker account is created:
- Switch to Burp's Proxy | HTTP history tab and find the maliciously executed POST used to create the account for the attacker, while riding on the authenticated session of ed's:
- Return to the User Info page: OWASP 2013 | A1 – Injection (SQL) | SQLi – Extract Data | User Info (SQL), and perform the SQL Injection attack again. You will now see 26 rows in the account table instead of the previous count of 25:
