[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.