Welcome back to using components with known vulnerabilities session. In
this second part. We will exploit a known vulnerability
in our Target application. We
will jump straight to our intentionally vulnerable application and
then move on to the mitigation Parts. In
previous sessions. We have seen that Juice Shop. Use Json, web
tokens to store some number of claims. These
tokens are stored, client-side, this cookies and in browsers, local
storage. There's a well known vulnerability in
some Json web token libraries.
He's allowing attackers to bypass the verification step. Let's
check. Whether Juice Shop is vulnerable to do that.
We will first create as a regular user account and
login to get a valid. Json, web token.
We can now retrieve our Json web token from
browser's cookies, or local storage.
Next, we will decode our Json, web
token.
Json web tokens, have three sections, all of
them Basics, T4 encoded and split by a
DOT.
The first section is called Heather and it includes information about
token type and the algorithm used to compute token signature.
The second section is called payload, and it holds the
actual data or claims.
The third and last section is the signature.
Tokens can be signed by the server, using a key. So
the serve is able to verify that the token is legitimate, when
it is sent back by the client in subsequent requests. The
signature is calculated, by base64 URL,
encoding, the header and payload concatenating
them with a period as a separator. And
passing the resulting value to an algorithm such as the age mock
sha-256 with the secret, the
name of the algorithm used to compute the signature is what
Goes into the Json web token Heather so that the same algorithm
can be used to verify tokens authenticity. This
was a quick overview of Json web tokens, but
you're better reading more about this since Json. Web
tokens are very popular and it's use widespread.
So now let's talk about the JWT common
libraries, vulnerability. We will try to exploit. JWT
library is have to implement at least two mandatory signing,
algorithms. None, and HS 256.
Then, an algorithm is
a curious addition to JWT. It is intended
to be used for situations where the Integrity of the token has
already been verified. Some libraries treated
token signed with the nun algorithm as
a valid token with the verified signature. You
Be seeing where this is going. We will replace the
out property in the JWT Heather of our token by
none. Then change some date in the payload section
and remove the signature. If Joyce
shop is vulnerable our tempered JWT should
be accepted.
Let's copy and paste. The JWT other into our
terminal to decode it.
Now we copy the decoded other modify, the out property, and
encode it back using basic C4, command line tool.
Let's copy and paste a new weather into our text editor. Attending a
dots to separate it from the payload section. We will append
here later.
We need to do the same with the payload. Let's copy
and paste it in to our terminal so that we can decode it.
Now we copy and paste, the decoded payloads modified
email property to something that should not exist in Jewish
shop database and encode. The modified Json payload using
base 64.
Again, let's copy and paste the outcome into our text editor.
We won't add a signature since, our talking is not signed, according
to our new JWT Heather.
Now we are going to replace the token in our browser's cookies
and local storage, with our crafted. Json web
token.
Let's no access some pages and see whether Juice
Shop. Accepts our crafted. Json web token.
As you can see, the Complaint Form shows the email address.
We replaced in the Json web token. Let's
see if we can post a message.
It looks like we have done it. Let's
check the customer feedback feature.
It also shows the email address. We replaced in the Json web token.
Let's also post some feedback.
Based on what we have experienced. The Json
web token Library used by Juice Shop is vulnerable. Next,
we will discuss what makes the application vulnerable and
how to prevent it.