Welcome to the third and last part of sensitive data,
exposure session. In this part. We
will discuss sensitive data, exposure mitigation. We
will start discussing what makes an application vulnerable. And
then, we will hunt a wasp to shop venerable source code.
Then we will discuss how to avoid such
vulnerabilities.
If your application does not use secure protocols, such as
HTTP, transmitting data in clear-text internally
or over the internet. Then
anyone in the middle will have access to the data. This
is also valid for dating rest. If
you're storing it in clear text including backup files, then
it is vulnerable. Hold or weak
cryptographic algorithms as well as default or we
cryptographic keys. Don't do much regarding sensitive data
protection re using crypto keys or
Ricky management rotation, we can
see encryption regardless the algorithm used if your server
does support encryption, but it is not enforced, due
to missing security directives, such as HTTP, security
others, then your date is at risk. The
same is valid when user agent for example, a mobile
app, fails to verify whether received server certificate
is valid.
Let's have a look at what makes Juice Shop vulnerable.
From ofjoy shop project page, we can jump
directly to the GitHub repo.
Let's first check how credit card details are handled by
the server.
Cards should be handled by the finale package and
all operations passed directly to the card model.
The card model implementation has just the schema meaning
that no operations are performed on user inputs before
being stored or read from the database. Let's
check the front end component.
Now, we know where the credit card number is masked.
Let's now have a look at the search feature to see
the source code. Vulnerable to SQL injection.
As seen in our first session, we have again, a
SQL query, template interpolated with user-provided data
without proper scaping.
You can now better understand the need for brackets. In
our payload. Let's move forward and
see how passwords are stored on sign up.
We're looking for requests made to the users and point.
Apparently signup is handled by the phenol package
passing data directly to the user model.
Let's have a look.
Okay, the password hash is computed, when setting the user models
password property value.
The insecurity hash function is used. Let's check
it.
Finally, we have found how password hashes are computed using
md5 with no salt.
Let's discuss how to mitigate these issues.
Start classifying all processed stored and
transmitted data identify, which data
is sensitive. According to privacy laws, regulations and
business needs then apply the appropriate controls
as per. The classification data
that is not retained. Cannot be stolen. Discard
the necessary data as soon as possible or use tokenization
or truncation to avoid sensitive data, exposure, choose
up-to-date and strong standard, algorithms, protocols and
keys.
Sensitive data dressed for passwords use,
strong, adaptive and salted ashing functions for
in transit data. Use secure protocols such
as TLS disable caching for
responses that contain sensitive data. In
our next session. We will discuss XE XML,
external, entities floss until
then take your time to carefully, read the sensitive data
exposure section of a wasp top 10.