In this lesson,
we're going to discuss cross-site scripting
and cross-site requests forgery attacks.
Now, cross-site scripting is a malicious script
that's hosted on an attacker site
or coded inside of a link
that's injected into a trusted site designed
to compromise the client that is browsing that trusted site.
Now, this allows the attacker to circumvent
the browser's security model or trusted zones,
and the attacker's goal in using cross-site scripting
is to get you to run some kind of malicious script,
so that your system will process this thing
and bypass its normal security mechanisms.
Cross-site scripting is a powerful exploit
that relies on your website
not conducting proper input validation.
If you're not doing proper input validation,
you are most likely going to fall victim
to a cross-site scripting attack.
So let's take a look at how cross-site scripting works
in the real world by looking at the four basic steps
of a cross-site scripting attack.
First, the attacker identifies
an input validation vulnerability within a trusted website.
For example, if my website
doesn't conduct proper input validation
for the username and password fields used
by my students, that could become a good candidate
for cross-site scripting attacks.
Second, the attacker crafts a URL
to perform the code injection against that trusted website.
At the same time, the attacker needs to get somebody
to click on that maliciously encoded URL,
so they might post it to a trusted website,
embed it in an email message using a phishing campaign,
or post it to an online forum.
The goal here is that the attacker needs to get somebody
to click on that encoded URL.
Third, the trusted site will return a page,
containing the malicious code injected,
as well as the regular site code.
This occurs once the user clicks the encoded URL
and the trusted site executes the code that was injected.
At this point, the user's going to be presented
with malicious content which they believe is trusted
because it came from the trusted website
that they were visiting.
Fourth, the malicious code is now run
in the client's browser finalizing
the cross-site scripting attack.
When this occurs, the code will run the permission level
of the trusted site because the system believes
the trusted site sent that code which technically it did
because it was injected into the reply coming
from that trusted server to the end user's browser.
This is why we call it a cross-site scripting attack
because malicious code is actually going to be injected
and served by the trusted site to their users.
Now, for example, let's say, I was scrolling Facebook,
and somebody was able to perform
a cross-site scripting attack there,
and they could inject code into my newsfeed.
Now, it's going to cross that threat actor site
into the trusted site, in this case,
Facebook, and then it's delivered to me,
the end user who's scrolling my newsfeed.
That's how a cross-site scripting attack works.
Now, cross-site scripting attacks can be used
to run malicious code that perform many different functions.
One attack may focus on defacing the trusted website
by injecting extra HTML code into it.
Another attack might focus on stealing the user's data
by stealing protected cookies from that user.
Another might try to intercept data
or communications as they're being entered
into the web forms, and yet another,
might try to install malware on your client's system.
As you can imagine, there are lots
of different things we can can do
with the malicious code being run,
but cross-site scripting is the initial delivery mechanism
that the threat actor is going to use
to get that malicious code to your system
and have it run by your web browser.
Now, the reason cross-site scripting is so dangerous
is because it breaks the browser's security and trust model
because browsers are going to assume that scripts
that receives from a trusted site should be safe to run.
Now, this isn't the browser's fault,
it's just because they're designed to run scripts
they receive from trusted sites.
That's how the internet is designed.
After all, if you go to my website,
there are lots of different scripts we're running
in order to provide you with the training videos,
quizzes, and practice exams that you want.
Your browser knows that it can trust my website
because there's a valid digital certificate,
and you've logged into our site,
and therefore, you're a trusted client,
and we're a trusted site.
Without this level of trust,
webpages would be extremely boring
because no scripts could ever be run or operated.
So let's take a quick look
at what cross-site scripting might look like
if we used it against a vulnerable website.
First, we're going to craft the URL by adding
the script to an otherwise safe URL.
For example, if my site was vulnerable,
we could use a URL, like diontraining.com/search,
question mark, q equals,
and then you'll see something like bracket,
script percent 20, type, equals,
quote, application/javascript,
end quote, bracket, alert, parentheses,
xss, parentheses, bracket, slash script, bracket.
Now, what does this really say?
Well, the first part here is simply saying we're going to use
a trusted website like diontraining.com.
The next part that says, search, question mark q, equals,
would normally be used for a website to conduct
a search for anything found after the Q equals
because that is my query.
For example, maybe, you're on my site,
and you're searching for the word CompTIA.
So you would see in the URL, Q equals CompTIA,
and that would send the word CompTIA to my server
to be able to search its database for any pages
that have the word CompTIA in it.
Now, because we're attempting
a cross-site scripting attack here,
we're actually going to replace the query with the script
that we want to insert.
In this case, I have a really short piece
of JavaScript code that's going to pop up an alert box
that says XSS when it goes and reaches the server.
Now, if you try to run this code,
it probably won't work on my website
because my site is already protected from this type
of cross-site scripting attack.
But if you want to attempt these on your own,
you could check out the cross-site scripting game set up
by google at xss-game.appspot.com,
which has six different challenges where you try
to create a cross-site scripting attack
against their servers.
The first one can be completed using
the example I just covered in this lesson.
Now, the example I just showed you
is what's known as a reflected
or non-persistent cross-site scripting attack.
This type of attack only occurs when it's launched
because you're clicking on that link,
or you're entering it into your web browser
and pressing enter.
When it happens, it happens once and then it stops
because it is considered non-persistent.
Now, there are other types
of cross-site scripting attacks though,
and these can be more dangerous.
For example, a persistent cross-site scripting attack allows
an attacker to insert code into the backend database
used by that trusted website.
By doing this, the attacker doesn't have to wait
for somebody to actually click on a link anymore
because the malicious code is now embedded
into that website's database.
Anytime a user loads the page or content from the database,
they're going to be loading
the persistent cross-site script as well.
Now, both persistent
and non-persistent cross-site scripting attacks
are considered forms of server-size scripting attacks
because it's a server that is executing
the scripts that we're injecting.
Now, there's also a client-side attack
known as a DOM cross-site scripting attack.
Now, DOM, is the Document Object Model,
and the document object model cross-site scripting attack
is going to exploit the client's web browser
using client-side scripts to modify the content
and layout of the webpage.
The document object model or DOM is how things
are displayed in the client's browser,
but by injecting scripts into the DOM,
you can actually change this.
Now, let me show you a quick example
of a DOM-based, cross-site scripting attack.
In this simple example, you can see a URL
of diontraining.com/index.html hashtag,
default, equals script, alert, document dot cookie, script.
Now, at first glance, this looks a lot like
the non-persistent, cross-site scripting attack
that I showed you earlier,
and both of these do have a short script
and an alert being issued, but the big difference
with this one is actually in the payload itself
because we're using the alert to show
the contents of document dot cookie.
Now, when you see the word, document here,
this is an indication that we're looking at the DOM
or the document object model inside of the web browser.
In this example, we're trying to access the cookie store
inside of the web browser's DOM,
and therefore, we're trying to execute this in the browser
and display the contents of those client's cookies.
If the web browser is vulnerable to this,
you're going to then see code go, oh, I see this code.
You're asking for document dot cookie.
You want to see what my cookies are?
Well, let me show you,
and we'll display those cookies
to the screen using this alert.
This again, is a simple example,
but there are many more dangerous ones out there
that could be used like document dot write,
document dot location, and other things that can access
and change the DOM environment.
Remember, when you're performing
a DOM cross-site scripting attack,
it's going to be run using
the logged-in user permissions for that local system.
So if you're lucky enough as an attacker
to have a system administrator who executes
your DOM cross-site scripting attack, guess what?
You now have access to that system
as a system administrator too.
Now, for the exam, let me give you a couple of quick tips.
First, anytime you're looking at a log snippet
or captured URLs that have the script
or any kind of JavaScript inside of them,
it's most likely going to be a cross-site scripting attack
that's going to be the right answer for that question.
And second, if you see something
with document dot something in it,
like document dot cookie or document dot right,
this should tell you it's a DOM-based,
cross-site scripting attack because it's affecting
the document object model of your browser.
If you keep those two tips in mind,
you'll do great on the exam.
Now, we're going to discuss cross-site request forgery attacks.
But before we do, we need to quickly cover
the concept of session management
because session management
is a fundamental security component
in our modern web applications.
Session management enables web applications
to uniquely identify a user
across a number of different actions
and requests while keeping the state of the data generated
by that user and ensuring it remains assigned
to that particular user.
For example, right now, there are hundreds
or thousands of people logged
into my site at diontraining.com,
all trying to take their courses.
Now, they're all doing this at the same time,
so we need to have a way to be able
to track which users are doing which courses
and which items in those courses.
So when you log into my website,
my website needs to keep track of your actions
and know which lessons you're currently watching.
It also needs to know which quizzes you've taken
and all of your different actions throughout the course.
And as you conduct those different actions,
we need to store the results of that in our database.
So when you log in next time,
you can resume the course at the right place
and not lose all your progress.
Now, as a developer, we can do this
by using our own server-side tracking using our databases,
or we can rely on cookies located on your client device.
Now, in the first web applications,
cookies were heavily used for tracking user actions
because HTTP is by default, a stateless protocol.
This means that the web server doesn't preserve
any information about the clients or their actions.
So in the good old days,
if you wanted to store information about your client,
you would simply store it as a cookie
on that user's computer.
A cookie is essentially just a text file
that's going to be used to store information
about a user when they visit the website.
That cookie is going to be created
when the server first sends
the HTTP response header
with that cookie over to the client.
Then any subsequent request headers that are sent
by the client back to the server should include
that cookie with the most updated information.
Cookies can be either persistent or non-persistent.
Now, a non-persistent cookie
is also known as a session cookie.
Session cookies reside in memory,
and they're used for a very short period of time.
When the browser is done with that session,
that session cookie is going to be deleted,
But some other cookies are more persistent,
and those cookies will be stored in the browser cache,
until they're either deleted by a user or they expire.
For example, if my website uses cookies
to track your movements and they're set
to expire after seven days,
those would be considered persistent cookies.
If you finished your work today,
but you came back in three days,
the cookie remembers where you were,
and it brings that progress back.
On the other hand, if you left for two weeks,
when you come back, the system might think you're
a brand new user because your cookies already expired
after you were gone for seven days.
When dealing with cookies,
those cookies need to be encrypted and secured
because they could contain sensitive information
in them as well.
All right. Now, that we have a little background
on session management and cookies,
we can move into session hijacking.
Now, session hijacking is a type of spoofing attack
where the attacker disconnects a host
and then replaces it with his
or her own machine by spoofing the original host IP
or using some other takeover mechanism.
For example, a lot of session hijacking occurs
by taking cookie theft or modification
of those session cookies.
Now, if the attacker is able to steal the session cookie,
they can take over the session
as the already authenticating user.
Now, another form of session hijacking focuses
on session management that's conducted using a database,
and this database will assign
a randomized session token to each user.
If the randomized scheme is not truly random in nature,
it'll create tokens that can easily be guessed
by an attacker, and this means they can predict your session
and take over the already authenticated session
by guessing your randomized token.
Session prediction attacks are simply
a type of spoofing attack where the attacker attempts
to predict the session token
in order to hijack your session.
To prevent session prediction attacks,
the session tokens need to be generated using
a non-predictable algorithm,
and they need to be truly randomized.
That way, the session tokens won't
be able to be easily guessed.
Also, those session tokens should not reveal any information
about the session's client,
instead session tokens should be a one-time use ticket
for the duration of a given session.
All right, now that we've established some background
and session management and session hijacking,
we can move into our discussion
of cross-site request forgery attacks, also known as XSRF.
Now, a cross-site request forgery attack
is a malicious script that's going to be hosted
on an attacker's site that can be used
to exploit a session started on another site
within the same web browser.
For this to work, the attacker needs to convince the victim
to start a session with the targeted website.
Once that occurs, the attacker can then pass
an HTTP request to the victim's browser
and spoof this as an action on the target site.
For example, if you're logged into your account already,
the attacker might attempt
to use a cross-site request forgery to change your password
or your email address for that account.
Cross-site request forgeries can be disguised
in a lot of different ways as well.
For example, cross-site request forgeries
can use things like image, tags,
and other HTML coding techniques to hide themselves.
The scariest thing about a cross-site request forgery
is that they can be accomplished
without the victim necessarily
even having to click on a link in order
for that victim to be exploited.
For a cross-site request forgery to work,
the website must have a feature that could lead
to unauthorized access,
something like a forgot-my-password reset feature.
And the site must rely on cookies for authenticating users
and use predictable patterns for session management
that can be guessed.
So let's take a look at a real-world example
of how this might play out.
First, let's assume the browser's already authenticated
to the target site.
In this case, the victim's bank.
That cross-site request forgery will then try
to steal the valid session token from that victim's browser.
For this example, let's assume there are
two tabs open in the web browser.
One is the attacker's website
and the other one is your bank.
Now, you've already authenticated to your bank,
but now, you've also connected to the attacker's website
inside this new tab because you clicked on a link
in a phishing campaign or another social engineering scheme.
Now, the attacker can use
a cross-site request forgery attack
to try to manipulate the session with your bank
because your browser is already authenticated to that site,
and they can attempt to take over
that session inside the other tab.
So, how can you prevent cross-site request forgery
as a defender?
Well, let's say, you're working for the bank,
and you want to make sure that nobody's going to perform
this against your customers.
What can you do? Well, first, you can ensure
that user-specific tokens are used in all form submissions
to prevent cross-site request forgeries.
This is an action that your web developers would take
as part of their secure coding and best practices.
Second, you can add randomness
and prompt for additional information
whenever a user tries to reset their password.
Or you can require two-factor authentication.
Third, you can require the user
to enter their current password
whenever they're trying to change their password.
This would actually stop
a lot of cross-site requests forgery attacks
because they usually try to change a user's password
without the user knowing it in order
for the attacker to take over that account.
Now for the exam, remember, that if somebody is trying
to get a victim to unintentionally carry out
an action on a website, this is normally going to be
a form of cross-site request forgery.
This most often occurs by trying to get
the victim to do some kind of unknown update
to their default email address
or by changing that user's password,
so keep that in mind for the exam.