>> Let's start off by talking about Code Injection.
It's exactly what it sounds like.
An attacker injects code into
a backend database through a website,
usually through a form that is open to the public.
We fill out forms all the time on the Internet,
anytime you are buying something
online or filling out a survey and so forth.
Of course, what we enter into those forms,
gets dumped into a backend database.
But the thing is, if I'm allowed to enter
garbage and it gets processed on the backend database,
it can actually run a command that is very harmful.
You don't have to be a SQL engineer
to know that the command in
this cartoon drop table
is probably not going to be good for your database.
What do we do to mitigate this?
Input validation.
We make sure that what goes into
our database meets our rules.
We're going to validate things like datatype,
so if the form is asking for a date-time,
I'll make sure that the only field
accepts that type of data.
We restrict the field linked to
limit what a malicious actor can do.
Or even better, we give you a drop-down menu to select
from so you don't enter
something in a field that can be damaging.
That's all part of the input validation.
Now, input sanitization is comparable,
but what it will do is attempt
to clean up what is being entered.
For example, let's say we allowed
12 characters for a last name field,
but your last name is 14 characters.
Maybe you enter all 14 characters,
but data sanitization is going to truncate
the last two characters so that
your information is input as 12 characters.
The answer to code injection is
input validation and sanitization.
Let me just tell you, that's
the answer to a lot of issues.
Well-written web applications that
make sure the interface or
the scripting that pulls the entry of
the user ensures the data meets certain requirements.
There are utilities that
perform what's referred to as fuzzing,
which makes sure that the application has
the proper input validation and sanitization.
Now, some people will talk about running
fuzzing tools to see if they can
exploit weaknesses and vulnerabilities.
It's just like anything else.
Anything that was developed for
good also can be used for evil.
However the context is presented on the exam,
think about fuzzing as something that checks
an application for weak input control.
Now, one of the problems that can come from
poor input validation is cross-site scripting.
Cross-site scripting is really a major vulnerability.
It's been around for years and keeps continuing to show
up on the top 10 lists of most common vulnerabilities.
It's really something that we need
to work on in software development.
It's specifically geared towards web applications.
We have three basic types of cross-site scripting.
We have persistent, we have reflective,
and we have DOM-based.
DOM stands for Document Object Model.
The first type of cross-site scripting
we'll look at is persistent.
As an example of this type,
let's say that before you took this class,
you got to know which instructor
you wanted to take this class from.
Let's say each instructor gets to create
their own biography for you to
read so you can make your selection.
When you click on an instructor's picture,
it switches and loads the biography.
But what if an instructor also
injected a malicious script into the picture?
When you clicked on the picture,
the payload did something like capture
your sensitive information from
your system and send it to the attacker.
You can see how that's persistent because it'll be
sitting there in the picture for
whenever someone clicks on it.
Now, just for the record,
nothing like this exists in the picture for
this course's instructor on the Cybrary site.
This type of attack could be done in a lot of ways.
I always think of dating websites and
how quick people are to click on this image
or that image and
all those files were uploaded by strangers.
Who knows what can be in there?
It's up to the site to ensure that it's
coded to catch that type of thing and
prevent it and that the data
that is going in is sanitized.
But with social media, there are million ways that
we could become vulnerable to cross-site scripting.
Now, with reflective
cross-site scripting, it is non-persistent.
This starts off with the attacker who creates
a URL that has some malicious string in it.
The attacker sends that URL to the user somehow.
User clicks on that link
thinking is for a legitimate site,
but ultimately it takes the user to a rogue website.
Once the user clicks the malicious
URL and goes to the site,
it runs its payload on the user system.
It might be that this code causes some of
that user's sensitive information to be sent back
to the attacker based on the user's connection.
This is non-persistent because it's based
on this link that the attacker sent to the user.
Now, the last type of
cross-site scripting is called a DOM-based type.
That stands for Document Object Model-based.
With this type, an attacker crossed a URL
containing a malicious string and sends it to the victim.
The victim is tricked into opening the link
and requesting the malicious URL from the website.
The website includes the malicious string
and its response to the victim.
The victim's browser interprets the malicious code and
the server's response as part of
the legitimate web page and executes code.
Then the victim's sensitive information
is sent to the attacker's server.
An example of this might be
a case where I go to the website
that the attacker has sent me
and it asks me to fill in my name.
I fill in Kelly and press Enter.
Then I see a welcome screen that says, hello Kelly.
It is taking my input and using
my input to launch a second page.
There's nothing happening on
the web server that's been poisoned, so to speak.
It's more about the fact that they've
manipulated the code, so that way,
it modifies with the website returns
when the user enters the input.
I hope that makes sense.
It's not that the website has been compromised,
but they've tricked your system
to provide input that is going
to cause some malicious return on the web server's part.
It's all happening in the victim's web browser.
No modification at all to
the web server and that's what makes it DOM-based.
It has nothing to do with
the interaction of objects on the same system.
Nothing is happening on the website.
It's more that your system is being tricked
into requesting some malicious activity.
Cross-site scripting can be really nasty.
It usually includes some manipulation
where you go to a website and
get something malicious in return.
The best defense from a web
server perspective is to write
clean application that validate input and sanitize it.
From a user's perspective,
you can keep your browser up to
date and disable JavaScript,
except where it's absolutely necessary.
Those are some things you can do to keep it safe.