In the previous article, we have seen some of the common data storage issues in Thick Client Applications specifically in DVTA. In this article, we will discuss some common injection attacks that exist in DVTA. We begin with CSV Injection followed by SQL Injection.

CSV Injection:

Comma Separated Vulnerabilities became popular lately. CSV injection is a formula injection technique, which can be used to exploit the export to spreadsheet functionality. The idea is to demonstrate the fact that DVTA application does not validate the data exported into the CSV file.

It is a common functionality in web applications as well as thick clients. This enables users to export data into an Excel sheet in CSV/XLS format, which can later be used with applications such as Microsoft Excel.

Let’s see how this works in DVTA.

Login as Rebecca and click View Expenses button to view the data associated with Rebecca’s account.

Note: If it does not contain any data, you can add it through Add Expenses button and then view.

The following figure shows the expenses of Rebecca.

Please note the Backup Data to Excel button, which can be used to export these expenses to a CSV file.

This is where CSV injection comes into the picture.

Can we tamper the expenses and add malicious data here? If yes, is the data being validated, before exporting it to the CSV file?

Let’s try to do it. Modify the value in price column and add a simple formula as shown in the figure below. Then, click Backup Data to Excel.

We should see the following confirmation window if everything went fine.

Perfect, now open up the CSV file using Microsoft Excel and notice the value in the price column. Excel has processed the formula placed while exporting the data.

To keep the example simple, we have placed a simple formula. However, you may try other exploitation techniques available online if you are interested in practicing it further.

SQL Injection

SQL Injection is one of the most common and dangerous vulnerabilities that we have been seeing for ages. Even today, developers are still making the same mistakes that cause SQL Injection vulnerabilities. DVTA also comes with an insecure code that causes SQL Injection vulnerabilities in it. Let us discuss how someone can exploit them in DVTA.

Let us see if we can use the most common SQL Injection string to bypass the authentication on the login page.

Please enter x’ or ‘x’=’x in both the username and password fields as shown in the following figure and then click Login.

Bam! We are logged in as Raymond. Traditionally, this is how SQL Injection looks like.

Let us see why this application is vulnerable to SQL injection. Opening up DVTA’s Github page and observing Login.cs will reveal the following.

It is clear that DVTA is receiving user input and passing it to a database handler using the function name checkLogin().

Next, open up DBAccess.cs as shown in the figure below.

As you can see, this is where the function definition for checkLogin is written. Again, it is taking the input supplied by the user and directly passing it to the SQL Query. So, we can confirm that Inline SQL Queries are written, and no input sanitization is performed during the login process.

Our next goal is to use this vulnerability to login to other users’ accounts assuming that we know their usernames.

Enter the following string into the username field.

Username: rebecca’ or ‘x’=’y’–

Enter any random value into the password field (This will not be executed as we are commenting it out in the username field).

Ethical Hacking Training – Resources (InfoSec)

Clicking Login button will show us the following window.

Excellent! We are logged in as Rebecca.

Can we use the same technique to login to Admin’s account? Oh yes! Let’s try it out.

Enter the following string into the username field.

Username: admin’ or ‘x’=’y’–

Once again, enter any random value into the password field.

Click Login, and we should see the following window.

Similarly, we can get into any account and perform operations on behalf of them.


In this article, we have discussed some commonly seen injection vulnerabilities in Thick Client Applications. We have seen how DVTA application can be exploited using CSV injection and then followed by SQL injection vulnerabilities. In the next article, we will discuss Reverse Engineering .NET applications and decrypting the database credentials hardcoded in the application.