In the first two articles we have seen the solutions for the first 6 challenges in DIVA. In this article we will discuss the “Input Validation Issues” in DIVA.

Challenge 7: “7. INPUT VALIDATION ISSUES – PART 1”

Steps to solve:

Click on “7. INPUT VALIDATION ISSUES – PART 1” in your application. Here is the functionality of this challenge. If you know the username, you can access the data associated with it. But, the goal is to access all the data without knowing any username.

When the challenge is launched following activity is shown to the users.

Since it has search functionality, my first assumption is that the app might be searching something from the database based on the user input. SQL Injection???

We need to test J

Let’s do a black box assessment this time rather than looking at the code first.

Let’s put a single quote (‘) and see how the app responds.

It seems, there is no response! Looking at the logcat output, I found the following log entry.

D/Diva-sqli( 2114): Error occurred while searching in database: unrecognized token: “‘‘” (code 1): , while compiling: SELECT * FROM sqliuser WHERE user = ‘

Good news! Possible SQL Injection. The above error shows that dynamic SQL queries are used to fetch data from SQLite db and the single quote we passed is causing an SQL error due to the mismatched single quotes.

Let’s add another Single Quote and see how the app responds.

.

Looks like the app is searching for the data entered and no SQL error.

To confirm SQLi, lets add another single quote and see if it causes an SQL error.

Following is seen in the logcat once again.

D/Diva-sqli( 2114): Error occurred while searching in database: unrecognized token: “‘”’‘” (code 1): , while compiling: SELECT * FROM sqliuser WHERE user = ‘”’

Perfect! This confirms SQL Injection. Odd number of single quotes is causing SQL errors. When quotes are properly matching the SQL query is properly executed.

What next?

Let’s use a string that always returns true to fetch the entries from the database.

We can use the string shown below.

1′ or ‘1’ != ‘2

As we can see in the above figure, we are able to pull the whole data from the application’s database using our malformed SQL query.

Following is the piece of code “SQLInjectionActivity.class” causing this problem.

Specifically, the following line of code is causing the issue as the app is receiving user input and inserting it into the raw SQL query without validating it.

Cursor localCursor = this.mDB.rawQuery(“SELECT * FROM sqliuser WHERE user = ‘” + localEditText.getText().toString() + “‘”, null);

Challenge 8: “8. INPUT VALIDATION ISSUES – PART 2”

Steps to solve:

Click on “8. INPUT VALIDATION ISSUES – PART 2” in your application. The functionality of this activity is to display some webpage that is entered by the user as shown below.

When you enter www.google.com as shown in the following figure, it should load it using a Web View.

The goal is to access any sensitive information from the device using this functionality.

If you remember, we have saved user data in shared preferences as well as on the SDCARD during insecure data storage challenges. Let’s try to read them.

We can use file:// as our scheme to read files. Let’s first see if we can read “.uinfo.txt” file created on the sdcard by entering the following input.

file:///sdcard/.uinfo.txt

Nice! We got the content of this file.

Let’s also check if we can read the XML file under shared preferences. Below is the command to be used.

file:///data/data/jakhar.aseem.diva/shared_prefs/ jakhar.aseem.diva_preferences.xml

Ethical Hacking Training – Resources (InfoSec)

Perfect! We are able to read the content.

Vulnerable Code:

Open up “InputValidation2URISchemeActivity.class” using JD-GUI. Following is the piece of code causing the issue.

The application is receiving the user input and processing the user-entered input with loadUrl without properly validating it. This is shown in the following code highlighted.

((WebView)findViewById(2131492995)).loadUrl(localEdittext.getText().toString());

This is the piece of code allowing us to read the files from the device file system.

Also note that we are able to read files from SDCARD since this application already has the following permission in its AndroidManifest.xml file.

<uses-permission android:name=”android.permission.READ_EXTERNAL_STORAGE”></uses-permission>

We will discuss the other challenges later in this series.