So now we've seen how hackers can actually
use our code against us.
They can send SQL commands in through our website,
and then perform actions against our database.
A very similar attack, it's almost
like a JavaScript injection, is what
we're going to talk about next.
What we're talking about this time is cross-site scripting.
So rather than sending SQL commands into our code,
they're going to be sending in JavaScript commands
through our code.
And still, just like we did in the last Nugget,
where we saw a way that we could practice it,
there's resources out there where
you can practice the cross-site scripting attack. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you can practice the cross-site scripting attack.
So let's talk more about how the cross-site scripting
attack works, and then roll up our sleeves
and see a little demo, or a way that we can practice it.
Let's get going.
The cross-site scripting attack is another big one.
It's kind of like an injection where we're inserting code
into the application.
Just like in the last Nugget, where
we were talking about maybe having a search bar where
we could inject SQL code, well now,
we're trying to inject JavaScript code.
And in order to understand where this attack is taking place,
you need to know a little bit about JavaScript because it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you need to know a little bit about JavaScript because it
is very JavaScript specific.
You see, again, when we go to a website, what we're really
doing is just downloading a bunch of files,
like HTML documents, CSS documents,
and JavaScript documents.
You can open these files up with Notepad
and see the underlying code.
Or take it a step further, if I actually bring a website back
up here, and press F12, this shows you the code
that you've downloaded.
Here's the HTML code, here's some JavaScript code.
When you see the script, there is the JavaScript itself.
And if you even go to the network section, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if you even go to the network section,
it will show you which files you've downloaded.
You get the idea.
All a web browser does downloads these little text documents,
and turns them into a website based on what
the text documents say to do.
So at the time that we visited a website,
our web browser is now holding this website in memory,
in its own memory.
And it's executing the HTML, CSS and JavaScript code.
So if we were to write a little JavaScript code here,
like trigger on alert, this JavaScript code WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like trigger on alert, this JavaScript code
could be executed immediately in our browser.
Now what are some other things that our web browser does?
For instance, if we log into a website,
our web browser is going to be holding a token or a cookie.
So it is theoretically possible that if the website itself
is poorly written, we could create a cross-site scripting
attack, send someone to a malicious website,
and then steal their token or cookie.
We could grab their token or cookie out of their website,
and do something else like email it to ourselves. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and do something else like email it to ourselves.
So the first thing you should know
about the cross-site scripting attack
is that it can attack content that's
within the web browser itself without ever talking
to a server or database.
But beyond that JavaScript can still
talk to a server or a database.
So it could perform similar malicious things
like we saw in the SQL injection.
This is all about exploiting the weakness in the website
code itself, and accessing resources
like servers or databases, or tokens or information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like servers or databases, or tokens or information
that may be stored within the web browser itself.
Within the web browser itself, this
is called the document object model, or the DOM for short.
So all items that are loaded by a website
can now be accessed by JavaScript using the DOM.
And just like in the last Nugget where
we had a way to practice the SQL injection,
this time we have a way to practice
the cross-site scripting attack.
And that's what we're going to do now.
Let's fire up a new website, and we'll
get started seeing how the cross-site scripting
attack can really work. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
attack can really work.
Now this website URLs a little bit longer.
I'm going to put it up on the screen,
you can see it now from my web browser.
I'm going to press Enter and it's
going to take us to this particular page
and this is cool there's actually
a bunch of different ways that you
can test your cross-site scripting skills.
But there's absolutely none that's
better than Google's very own cross-site scripting game.
You see if we go to the Google cross-site scripting game,
it tells you up front that Google
will pay people to report cross-site scripting
vulnerabilities or bugs.
Look at that, that's not a small amount of money, 7,500 bucks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Look at that, that's not a small amount of money, 7,500 bucks.
So what they're trying to do here
is they're trying to train you how to find and exploit
cross-site scripting vulnerabilities,
so that you can report it to them,
and they can help you out.
So this is a little game that will actually
walk you through like trivia on how
you can execute cross-site scripting vulnerabilities.
If we click let me at 'em, here's our first one.
You can toggle the target code here,
and it will show you a little Python code that's written here
that hasn't been written in such a way
that it will handle stopping the injection of JavaScript code. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that it will handle stopping the injection of JavaScript code.
You see in HTML, when we want to write JavaScript code,
we simply write a script tag.
Now our challenge here is to fire off the alert JavaScript
code.
This is when it pops up on your screen
and says an error has occurred.
And then close the tag with a script tag
this is going to be sending in an HTML script of JavaScript
code saying alert.
So I typed this in and click Search.
And look at that it actually fired off the JavaScript
alert in my very own browser. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
alert in my very own browser.
So if we move on to the next attack target here,
it shows us a little bit more.
Now we're looking at a message forum
and if we toggle the target code here,
it's again some Python script.
But this time it's been written to handle these script
tags so that we don't inject script
tags with-- into the code.
But there's still ways that you can
handle, or send in JavaScript code with other tags.
A popular one is through the image tag,
where we want to embed an image into our website.
So what we can do to actually send in JavaScript code
without using a script tag is we can use the image tag, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
without using a script tag is we can use the image tag,
but force it to throw an error.
You see, if I say an image with no source,
that will obviously trigger an error.
And we can say upon the event where an error occurs,
run this JavaScript code.
I'll close the tag here and hit share look at that.
There we go.
So you can see immediately, there
are a few different ways that hackers can send
in malicious JavaScript code.
And ultimately, they can perform whatever
actions they want you on the server,
as long as the web application or JavaScript WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as long as the web application or JavaScript
itself can access that.
And just like before, it can access anything that's
in the DOM at this point too.
So if the application or the security section
were holding tokens JavaScript would
be able to exfiltrate those tokens
and send it wherever we want.
So that's been the cross-site scripting attack.
I hope this has been informative for you,
and I'd like to thank you for viewing.