[MUSIC]
Hey, welcome back.
In a previous lesson, we talked about how to get our code from GitHub, how to
set up your IDE, and even how to run that code inside of a Docker container.
Now we will transition into secure programming in Java.
In this lesson, we're going to introduce cross-site scripting,
also known as XSS, what they are, and how they affect us.
After this lesson,
you'll be able to cite a few recent examples of cross-site scripting attacks.
You will be able to recall three different types of cross-site scripting attacks.
You'll also be able to describe how they happen and how to guard against them.
This is important foundational material, so let's get started.
Injection attacks are one of my favorite types of attacks.
And before we dive too deep into it, we need to understand
what injection attacks are at their core and how the affect us.
So historically injection attacks have been used to compromise,
to do very large compromises, most notably is the Equifax
breach of 2017 that started unfolding into 2018 as well.
That was an Apache stress vulnerability that led into a deserialization attack,
but at its core, it's essentially an injection attack.
LinkedIn famously has lost millions of user records because of
a SQL injection attack, Yahoo has been vulnerable to an injection attack.
And injection attacks tend to make headlines just because of how
severe they can be.
Now, we'll dive into what causes this, but there's many types of injection attacks.
And we want to break that apart just so
that we have a clear understanding of it, right?
So injection attacks can happen in a lot of different places.
You may have heard of SQL injection, but
there's many different types of injections.
There is OS command injections, there is LDAP injections,
X-Pack injections, NoSQL injections.
And even attacks like cross-site scripting, which in OWASP
language has its own category under cross-site scripting.
But at its core, it's also an injection attack,
except the injection is taking place on the client side rather than the back end,
and hence the difference between how they're represented in OWASP.
So with that background, let's kind of talk about how injection attacks happen.
And in order for us to be able to speak about it,
I'm going to show you a little bit of SQL and a little bit of JavaScript,
just to show the back end and the front end version of this.
And then we'll dive into WebGoat and go through the various lessons for
cross-site scripting under this module.
And then on the next module we'll pick it up with injection attacks that
target our back ends, like SQL and command line injections.
So let's talk about the various types of injections.
So on the left, and I'll minimize the window on the right just so
that we don't lose focus here.
On the left, we have a simple page,
it's ten lines of code, most of it is just HTML boilerplate.
Really, the meat of it is on line seven.
And this is in PHP, just for simplicity sake,
it allows us get a very basic web page up.
And all it's doing it's echoing the world Hello and
concatenating to it whatever is on the URL with the parameter of name and
then adding an exclamation point at the end of it.
So if I open that up in my browser,
You'll notice it will just say, Hello, space, exclamation point,
and that's because we didn't pass anything to it.
We could pass it something like name, Joubin, and
you'll notice it'll say, Hello Joubin!
This gets kind of interesting because you could also do some nefarious things.
I can type in an entire script, and
maybe I want to alert myself to something, and end my script.
So what we would expect in this scenario for
our page to show Hello, and
add to it the script tags and the alert(1).
Now, this isn't going to work because Chrome and
most modern browsers have some built-in facilities to detect
these baseline-type attacks, and they simply block it.
You can launch Chrome with some command line flags to prevent it from doing this.
This won't be an issue when we're going through WebGoat because WebGoat's
been engineered to detect these things via code rather than
by having the browser actually react to something.
And it's in the stuff that Chrome doesn't, it doesn't allow for
Chrome to intercept it.
Also, there are some headers that WebGoat sends to disable some
of these facilities as well.
But for the purpose of this demo, I have a version of Chrome that is vulnerable.
I've modified the code to it to disable XSS Auditor.
And if I simply put in that same Hello, script, one,
script, you'll get a pop-up that says 1.
Now, if you look at the code of this, what you see
is is that Hello and this script has simply been injected in this page.
So my browser is simply opening the browser, and
from top to down interpreting what it sees, and it comes across script tags.
And in browser language,
that basically means interpret the following as a script that I've written.
Now, alert(1) basically gives you a pop-up and shows you the number 1.
I could do something a little bit more interesting.
And I can type in some text, and that text will show up.
Or I could even do more nefarious things, like stealing cookies and sending it off.
Essentially anything I put between these script tags
is code that's being executed in the browser.
So conversely, if you have something like a SQL injection,
That's where you have a string, maybe like this,
select * from users where id =, and then you concatenate onto it some id.
Now, if you're familiar with SQL language,
select * means select every column from, and then some table
name with some condition, in this case we're saying id =.
Now, if the user was nefarious with this concatenation,
the user could simply provide an id,
maybe they provide a blank id, and they could also say or 1=1.
This could be what the user provides to us in this variable, right?
This could be the user's inputs.
And when our SQL driver simply interprets this, it's going to read select
every column from a table where the id is blank or the id is true.
This will result, simply because 1=1 is a true statement, this
will result in SQL simply returning every single record that it has in that table.
And that was all because our user provided this as the input.
So in this example, we could
consider user.id to be equal
to this, To be equal to that text.
And that's all the user needs to provide to get everything to come up.
So essentially injection attacks is where the attacker gets to mix code,
or SQL language, or JavaScript, or
some OS commands in between the developer written code and get them to execute.
So that's a very, very basic understanding of injection attacks.
And in the next module, and
in the next videos we'll discover a little bit more about cross-site scripting and
different types of injection attacks and how harmful they can be.
At any point, feel free to go to the OWASP homepage, or even on Google, and
search injection and you can read a little bit about how injection attacks happen.
And in fact, at any point when you're developing code in your professional life,
you could simply write injection cheat sheet.
And then say you're working in Java, you would add the Java.
And you'll notice that OWASP has a cheat sheet for Java to prevent injections.
They explain injection attacks.
We're going to go much deeper into this.
But if you're writing code and you forget some of the primaries or
some of the basics of this, you can always come back to this point and
look at the various resources that OWASP makes available.