All language subtitles for 022 Data Sanitization_Downloadly.ir_en

In this lecture, we're going to use

two more packages to improve our application security,

and this time to perform data sanitization.

So, data sanitization basically means

to clean all the data that comes

into the application from malicious code.

So, code that is trying to attack our application.

In this case, we're trying to defend against two attacks.

So, let's write it down, and we will do it,

let's say, right here after the body parser.

This middleware here reads the data

into request.body, and only after that

we can actually clean that data, right?

This is a perfect place for doing the data sanitization.

So, we will do data sanitization against

NoSQL query injection, and also data sanitization

against cross-site scripting attacks.

And now before doing anything else,

let me show you why it is so extremely important

to defend against this type of attack.

We will now simulate a NoSQL query injection

and I hope that you will be as shocked as I was

when I first discovered how powerful this can be.

Let's now head over to Postman here,

and try to log in as someone, even

without knowing their email address.

All right, so basically, simply giving a password,

let's say this one here, we will be able to log in,

but even without knowing the email address.

Again, we're going to do that by

simulating a NoSQL query injection,

and the easiest way of doing it goes like this.

Instead of specifying a real email,

we specify this query, basically.

We use the MongoDB greater than operator

and set it equal to nothing, okay?

And now, what happens?

Indeed, we are now logged in as the admin.

So you see we even got our access token.

Yeah, we're really now logged in,

and this completely blows my mind, okay?

Again, without knowing the email address,

only the password, we were able to log in.

And believe me, it's not really difficult

to find a bunch of really popular passwords

that are used on every application.

So, this kind of attack is what we need to protect against.

This works basically because this will always be true,

so that's actually - you also see that in Compass.

So I'm copying it, or actually, let's copy all of this.

Then try to filter by this exact same thing.

Now we're just missing the curly braces,

but now we actually get a valid query.

Let's hit Find, and indeed, this returns all of the users.

So basically, all of the users match this query.

Again, it is because this here is always true.

That will then select all the usernames.

That malicious query injection here allowed us

to log in only knowing this password, all right?

So, to protect ourselves against this,

let's install another middleware,

and this one is called express-mongo-sanitize,

and since we're here, let's also go ahead

and install the other one that we're going to need,

but later in this video, which is called simply XSS.

Actually, that was not correct; it's called XSS_clean.

We need to go ahead and uninstall the other one.

NPM uninstall XSS.

Let's take a look at our package.json, and indeed it's gone.

Again, XSS_clean is the one that we want to use.

Anyway, first, let's talk about

the NoSQL query injection again.

All we're going to use is - and of course,

we need to first require it, so

const mongoSanitize equals require express-mongo-sanitize.

Again, VS Code here helps me, and since we're here,

let's also require the next one.

The variable I'm requiring is called XSS,

and then the name of the module is XSS_clean.

So, let's now use this mongoSanitize here - right here.

MongoSanitize is a function that we will call,

which will then return a middleware function,

which we can then use.

This is enough to prevent us against

the kind of attack that we just saw before.

So, what this middleware does is

to look at the request body, the request query string,

and also at Request.Params, and

then it will basically filter out

all of the dollar signs and dots,

because that's how MongoDB operators are written.

By removing that, well, these operators

are then no longer going to work.

So, let's try that again.

Again, it will remove all of these dollar signs.

So if I do this now, then indeed,

we get this error, and we can

no longer use this trick here,

this query injection attack, to log in.

So, that fixes the first problem,

but now let's use that other middleware

that we also just required before.

So, app.use and XSS, all right?

This will then clean any user input

from malicious HTML code, basically.

Imagine that an attacker would try to insert

some malicious HTML code with some

JavaScript code attached to it.

If that would then later be injected into our HTML site,

it could really create some damage then.

Using this middleware, we prevent that

basically by converting all these HTML symbols.

As I said before, the Mongoose validation itself

is actually already a very good protection against XSS,

because it won't really allow any

crazy stuff to go into our database,

as long as we use it correctly.

Whenever you can, just add some validation to

your Mongoose schemas, and that should mostly protect you

you from cross-site scripting, at least on the server side.

Let's just very quickly test this middleware here, as well.

What I'm going to do is to simply create a new user,

and let's call it "tester" here or something like that.

The password is right, and here,

in the name, let's add some HTML code.

So, div with the id of bad-code.

All right, let's try that now.

You see that the XSS module that we used

actually converted these HTML symbols here,

mostly this one, into this HTML entity here.

Let's just quickly delete this guy.

We don't need him at all. (Laughs)

That is our quick and easy protection against

some of these attacks using data sanitization.

Also remember that the validator function library

that we used before also has a couple of

cool sanitization functions in it.

We could also manually build some middleware using these,

but again, that's not really necessary,

because Mongoose already enforces a strict schema.

Then, if it encounters something weird,

it will then throw an error, and yeah,

that's already a pretty good protection.

So, we're really almost done with the security part.

All we need to do in the next video

is to prevent Parameter Pollution.