Welcome back to injection floor session in
this second part. We will exploit an injection flaw in
our intentionally vulnerable application before
the actual exploitation. I want to introduce you
to a wasp Joyce shop, our intentional vulnerable application. After
that. We will practice, what? We have discussed in the first part
and bypass owasp Jewish shabbat indication exploiting
a SQL injection vulnerability. I'll
ask dress shop is yet another of us project led by Bianca
minutes.
Each. It's an intentionally vulnerable application aimed for
application security training. There are several applications like
this one. Even some of them under the WASP umbrella, but
this is up to date with the latest version of
the last top 10.
This is the last Juice Shop project page, where you'll find a
lot of information about the project and the application itself. After
completing this session, come back here and
check the available information for now. Let's focus
on the application architecture.
On the left. We have the client web application written
in JavaScript using the popular angular framework,
Droid shop supports authentication with
Google accounts.
Then we have the back end where there's an API server running
written in no GF.
The API server interface with the file system and SQL database,
which support sequel for data
management. If you're curious about implementation, you
can have a look into the source code in the projects, Rebel.
We all come here in the third and last part of this session
so that you can see how the vulnerable source code. We
will exploit next looks like without further delay.
Let's hack.
If this is your first time with just shop, pause
the video and take a while to play with it and see
what features it offers for now. We
will sign up for a regular user account.
Let's now login with our new account. But first, let's
pop-up browser developer tools and switch
to the network tab so that we can see both client requests in
server responses.
The login request, should be a post request to
the success status code such as 200.
Let's check the details.
Our authentication credentials email and password were
sent as a Json object.
Server responded with the Json object to
with several tokens and
our email.
Let's see how our account profile and then review what happened
behind the scene.
The provided authentication data was
sent to the backend server where it was merged with SQL, query
template and then sent to the database here.
We can see the SQL, query received and executed,
by the database server. There's only one row
in the table, that matches our email and password hash,
and this gave us access to our
account.
Now, let's hack first. We need to
log out from our regular user accounts. Then we'll open developer
tools switching to the network tab.
This time instead of providing a valid email
address. We will first check what the server response is,
if we send a single quote character and
a random password.
Notice that this time the login post request has a 500 status,
goes internal server error.
The request data is exactly what we entered in
the form.
The response still in Json format. This
time is an error object, including the query
sent to the database where we can see that our
single quote character wasn't escaped.
This means the application is vulnerable to SQL injection. Let's
improve our payload and resend the login request
with the random password.
The network tab. We can see that the login request was
successful.
Let's check the details.
We can see that what was sent was our payload in
an arbitrary password, the server sent a
Json object, with some tokens and the
admins email address. Let's check
our account profile to confirm that we are authenticated Azad
mean.
So what happened now in the back end server, we
can see how the client provided data was merged into the
SQL query template on the right. The final SQL
query sent to the database server. Let's look at
it in detail.
There's no record in the table with an empty email address, but
one is equal to 1 for every record in the table.
The semi column breaks. The SQL statement in
no. More conditions are checked. Until this statement is
executed and the result returned back to the backend server.
All records will be returned. But since
the back end is expecting just one record only. The
first one will be considered. Luckily, for
the attacker. The considered record is the
admin one. Meaning that attacker gets access to
Application as administrator in. Our next
video, we will discuss what makes the application vulnerable and
how to prevent it.