-: Web application vulnerabilities.
So our web application vulnerabilities
really fall into three main categories.
We have injection attacks, we have Cross-Site Scripting,
and then we have this Cross-Site Request Forgery one
which may or may not be considered a vulnerability
as much as it is an attack but
we'll talk about that as well.
Now we talk about injection attacks,
the most common of these you've
probably heard of is an SQL injection.
These are going to allow you to send commands through
a web server to a back end system and
that'll bypass the normal security controls.
Like I said, SQL injection is probably the most common
but you can do this with pretty much any server language.
In the old days we used to use it with CGI,
you can use it with Pearl and others.
You can prevent this though through input validation
and using lease privilege when your accessing things
like databases and back end systems.
So, how does an SQL attack or an SQL inject really work?
Well, let's say I had a web form
that's asking for user name and password.
So I as a normal user, I would put in Jason
and my password of my password.
When you do that, it sends a command
to the back end data base system, to the SQL.
It says select star from users where User ID is Jason
and the password is my password.
If it's written like that, no problems.
It goes, if I put in Jason and my password matches
the data base password of my password, then guess what?
I was good and I'm gonna get into the data base.
Now, where does the SQL injection come in?
Well, on the bottom half of the screen you'll see
User ID instead of putting Jason, I put an escape
character, OR, one equals one, semi-colon, and then a slash
and a star which starts a comment line.
And then in password I put the end of the
climate line and dash dash, right?
And so what that sends to the data base is select star
from users where User ID equals break out character or
one equals one, comment, the rest of the things.
So, when does one equal one?
Well, one equal one always is true and
so that's what's happening here.
It's tricking the database and going, oh, something
that's always true means his password
doesn't matter it's always true.
And that's what you're going to see here.
So if you're ever answering a question on SQL injects and
you're trying to take the CSA plus exam for instance and
you see something where it's a number equals a number, like
one equals one, twenty equals twenty, a hundred
equals a hundred, that's an SQL inject, okay?
Keep that in mind, and usually it will have
a break character or one equals one.
A break character or six equals six, something like that.
That is gonna give them access to the data and then
they can start sending commands over that they want to send.
The next type of attack that we can have or vulnerability
we have is a cross-site scripting error.
This is gonna happen when an attacker is able to
embed scripting commands on the website.
And so when a regular user goes there,
they're executing those commands without even knowing it.
That's why they call it a cross-site script,
because they're putting the code in the site.
Now a lot of the ways that this was
happening early on was through ad programs.
You could buy ads on, you know, Google's ad network
and if they weren't catching this code when they
displayed your ad, it actually was sending users over
to your site, right, and things like that.
So the victim in this is the regular itself not the server.
You're not attacking your web server but
the coding that you have on your site.
And so if you discover one of these,
what you're gonna have to do is if it's coding on your site
that's bad because they've gotten in through some other way
like remote code execution and
have now changed some of your web files,
you're gonna need to work with the developer
to fix the code make sure that cross-site scripting
does not exist on your web site.
And this will help prevent it from being in the future
and the vulnerability being exploited against your users.
Now, the last one we're gonna talk about here
is what's called a cross-site request forgery
which is a little bit further than a cross-site script.
In this case the attacker doesn't
have access to your server at all.
They weren't able to change the files.
Instead they're gonna cause a user to execute actions
on the web server which they're already authenticated.
So what does that mean?
Well, I logged into my bank account to check my balance.
I'm authenticated on the web site.
If they could do a cross-site request forgery,
they can send a command like transfer money
from Jason's account to John's account.
The attacker can't see what the web server sends back,
they can just send commands to it and
then they gotta just hope the commands work, right?
This attack can be used to transfer funds,
change passwords and other things
based on getting this fraudulent request in.
That's why we call it a forgery and have the user execute
it on our behalf without them knowing.
Usually this is combined with some other piece of malware
or some other vulnerability as well.
Now, when we look for these things we have to look for
web application scans and Nessus can do it,
Qualys can do it but they don't do it great.
They're not designed for that, right?
They're good at scanning the server itself but
not necessarily the server's code.
And so we want to use a tool that's
specifically meant for that, something like Nikto.
And Nikto is a great tool that comes by default
inside Cali Lenox and you can actually look at
your web servers and look at the code on them
and find the vulnerabilities and
give you a much better idea of what's on them.
So, if you're thinking about your web applications
and your running a web server, yes,
you still want to scan them with Qualys or Nessus from
the patch management standpoint and those vulnerabilities.
But if you're looking at the code itself,
you want to look at a specialized tool
like Nikto or some other commercial equivalence.