Exploitation: Set Up Your Store

Welcome back to Sensitive Data Exposure session. In this second part, we will exploit our intentionally vulnerable application to get access to some sensitive data. We will jump straight to the hands-on exploitation. Before closing, we will review what’s wrong with our target application. Let’s hack. Before some shopping, let’s configure our default address and payment methods.

All right, we are now ready to buy some juice.

Let’s review our order and proceed to checkout. In the next step, we should be asked to select a payment method. Let’s pop up developer tools so that we can inspect what data is exchanged between the browser and the backend server.

See how credit card number is masked in the interface. However, if we look up the request to retrieve credit card details from the server, we will find something completely different.

The credit card number was sent in clear text. Since the application does not use HTTPS, anyone between client and server will be able to see it as any malware installed on the client device.

Let’s complete our order and see how far we can go exposing sensitive data.

On our first session, we exploited the SQL injection vulnerability to bypass authentication. In that case, we could not retrieve any data from the database since the backend server was just counting matched records instead of returning the actual results. If we find a vulnerable endpoint that asks for user inputs to merge with a query template returning phone records, then chances are we will be able to access arbitrary data on the database. Usually, search features are good candidates. Why not try our luck? Let’s pop up developer tools and search for orange adding a trailing single quote character as we did in the injection flow session to exploit SQL injection.

Apparently, nothing happened. Better opening to get request in a new tab so that we can easily modify the QUrl perimeter.

Let’s do it again.

Okay, this time it looks promising. We now have a SQL error.

The percentage character is a good sign that the SQL-like operator is being used, but think how the backend query template may look like.

This could be the backend query template. Let’s replace the input keywords with our current payload and see how it looks like.

Another SQL error. This time, the query is incomplete. Maybe the query template tries to match our search keyword both in product’s title and description.