Hello and welcome to the cyber very secure coding course. My name is Sonny Wear, and this is a WASP top 10 for 2013 a six sensitive data exposure. So first, let's take a look. At our definition.
Many Web applications do not properly protect sensitive data.
Now, examples of sensitive data can include but are not limited to credit card numbers as ascends authentication credentials. And so when they don't protect thes sensitive data elements or fields with appropriate encryption or hashing,
Attackers can then steal or modify
this data and, of course, conduct identity theft, credit card fraud and other crimes.
Now, if we take a look at our AWAS chart for a six sensitive data exposure, we can see that the attack vector exploit ability is difficult
and that the technical impacts or business impacts are very severe. Now, if we take a look at the description for the security weakness, it says, the most common flaw in this area is simply not encrypting data
that deserves encryption.
When encryption is employed, unsafe key generation and storage not rotating keys and weak algorithm usage is common.
Use of weak or unsalted hash is to protect passwords is also common.
External Attackers have difficulty detecting such flaws. Due to limited access,
they usually must exploit something else first,
to gain the needed access we're gonna describe in more detail some of these actual scenarios, as well as a better understanding of the difference between
using encryption algorithms and hashing functions. So first, let's talk about unprotected passwords. Now there are passwords that are used for different purposes. There are, of course, passwords that are used by users in order to log into an application.
And then there are passwords that are used by applications to actually connect to other systems, usually databases. So if we first take a look at the passwords used by users,
these passwords should always be hashed
when they're stored in the database.
Now half is a one way encryption,
and it is not reversible, and it also needs to have something called a salt. So a salt is some sort of peace of randomness that is added to the hashing function
in order to strengthen the algorithm.
And so the salt is usually added with the password that you're going to hash
and then together that information is stored securely in the database. And there's a lot of reasons for this. The main reason. It's so that programmers or system people or whomever, cannot just see somebody's password, right. So it protects the user's password
from actually being seen by unauthorized eyes.
Now, in the case of passwords that are used by applications,
these actually do need to be reversible. And so these passwords generally will use some sort of symmetric algorithm. They'll actually use encryption algorithms in order to be encrypted and decrypted.
Now, applications that connect to databases or other back in systems
use some sort of account i D. And they have a password. Ah, lot of times this information can be stored inside of configuration files.
It's very important that they are not stored in clear text. Obviously, this exposes the sensitive information,
and it makes it much easier for an attacker that is able to sniff, let's say, on an unencrypted line
to sniff that password and be able to connect to the database.
Now, another area where we could have a problem with exposing sensitive data is data leakage through memory compiler settings. And really, this is
to address any kind of memory leakage issues where data could be exposed.
So in this particular example, we're looking at some C code,
and the use of mem set here
with an optimized compiler setting will actually leave the buffer as a dead code.
Now, that could be a problem, because that dead code is left resident in memory.
And so if attacker were able to sniff
information or rented a bugger on this process, you would very easily be able to see
any kind of sensitive data that could have been, maybe in a transaction. Maybe it was a credit card transaction or something like that. And so the contents of that buffer would still be viewable. Now, another area that programmers may forget is logging.
So from the CERT secure coding standard. We're looking at this rule, and it's basically states do not log sensitive information outside a trust boundary.
I'm actually gonna take that one step further
to say that you should never log sensitive information, And if you do, you should mask it in some way. If you need that piece of information for
troubleshooting purposes, client assistance purposes, then make sure that that information is properly masked. Sensitive data can be a number of different things. As you'll see in the demos it can include I p addresses, maybe of
remote client connections that come in.
It could include, of course, user names and passwords,
email addresses. Now that's an interesting one, because we probably normally don't think of our e mail addresses being sensitive. But
if it's being used for the user name,
then certainly that could make it sensitive. And also,
for, say, a password reset type function.
And so it's important that that information get protected. And that, of course, any credit card information,
whether it's the credit card number, the expiration date, et cetera, all of those type of fields which fall under PC Idea says regulation also must be protected
in the realm of personally identifiable information or P i. I we have things like so security numbers, driver's license numbers, passport numbers, et cetera,
fields that uniquely identify you. And so, if those air stolen, of course, you could be susceptible to identity theft. Now, in our noncompliant example that we have here,
in this try catch block,
there is a remote I P address that is captured from the
I met address dot get by name.
And if there's some sort of exception,
then that actual machines host address is then logged. This has the potential of exposing sensitive data, namely the I. P address of our remote client.
Now, in this compliant example,
we can see that the programmer is only going to log information that's captured in the security exception. Class itself
now realize that that class, of course, has to also not be written to log in the sensitive data. So I'm making this compliant contingent upon that the custom class isn't logging any sensitive information.
Now our case study is on an interesting website
that is plain text offenders dot com.
Basically, this is a website that alerts and users of various sites where password information is not being hashed in the database, and this is made known because
when the user goes to maybe reset their password or they forgot their password or something like that,
the actual password is e mailed back to the user.
So that tells you that
either they're not hashing the password, leaving it in plain text or they're using an encryption algorithm that is reversible and so they are decrypting it. But either way it could have, ah, memory exposure. It could also,
of course, being sent through email be very easily lifted
in various email Web accounts. And so this is a very good example of sensitive data exposure.
Now let's move to the demo portion of our modules.