- In this lesson, 8.5,
we're gonna focus in on application attacks.
Now the objective of an application attack
is to either manipulate the input,
what is sent to the processor, or the output.
So one of those three,
the input, what's processed, or the output.
So we want to always be validating what is being input,
what is being sent to the processor,
or what's being output.
The validation being the process of enforcing
and verifying the desired level of compliance at all stages.
Input validation is the process of properly validating input
from the client or the environment.
And output validation is used to control
what's returned to the screen.
Application attacks can be very powerful and very dangerous
and yet there are some really simple
straightforward things that we can do
like input and output validation
which will incredibly diminish the success of an attack.
So let's look at four common application attacks.
Injection, cross-site scripting, cross-site request forgery,
and directory traversal.
An injection attack tricks an application
into including unintended commands in the data
that's sent to an interpreter.
An interpreter's just a fancy way of saying the processor.
And we see injection attacks against operating systems,
LDAP, lightweight directory access protocol,
and SQL databases.
A cross-site scripting attack known as an XSS attack
is the injection of malicious code either
into a web application or backend database
that will execute scripts ultimately
in the victim's browser.
Now, there are two forms of a cross-site scripting attack.
There is persistent and reflective,
and I'll go into that detail in just a sec.
Then we have a cross-site request forgery,
known as a CSRF attack,
which tricks a web browser into
executing a malicious action on a trusted site
that the users already authenticated.
The CSRF exploits that trust
that the site has in the user's browser.
Our fourth attack is a directory traversal.
A directory traversal attack uses specially crafted input
that includes dot dot slash sequences
to traverse a directory and access files
or directories that are outside of the intended scope.
Now down on the bottom here,
you can see a link to an owasp site.
Owasp has a really good article and an explanation
of a directory traversal.
So if you're interested and you want more information,
that's the place to go.
So let's go through each one of those attacks.
We're gonna go through an injection attack.
We're gonna go through a persistent
and reflective cross-site scripting,
and we'll go through a cross-site request forgery attack.
So here's what I want you to imagine.
I want you to imagine that you're an attacker.
And what you wanna do is you wanna extract some information
from an organization's database.
And you're thinking, okay how do I do that?
Well you as the attacker say,
hmm let me go look at their website.
Are there any forms on their website?
And like wow, yeah, there is.
There's a form to request a white paper.
Well, that would be interesting
because anybody who's requesting the white paper is
either a client or maybe wants to be a client.
And if I'm the attacker and I can
get that potential client information out of there,
I can use that in a social engineering attack
going after those clients.
So I look at the form, you know the website,
and I say yep, there's a form, right?
That form to request the white paper.
Now maybe the form is just very simple.
It's saying what's your first name, your last name,
your phone number, and your postal code.
Well, if there was input validation
the first name might be restricted
to let's say, 16 characters all alpha.
Maybe the last name is 18 or 20 characters, all alpha.
The phone number is probably a country code,
an area code, three numbers, and four numbers,
but all numeric.
And maybe a postal code is either
five or maybe with a dash eight and it's alpha numeric,
but no special symbols.
Maybe it's also even asking for an email address.
So an email address we know could be fairly long.
It could be alpha numeric,
but the only special characters allowed
should be a period and an at sign.
So with input validation, we put those parameters,
we mean the developers would put those parameters
in the form and say that's the only thing
you can put in that form.
But the attacker goes to the form and says,
I wonder if they have input validation.
Turns out they don't.
So instead of putting in a first name or a last name
or any of the other fields what they're supposed to be,
the attacker sends the attack string,
in this case just a SQL query in the form data.
Well that information gets forwarded
to the backend database.
So the application forwards that attack string
to the backend database.
The backend trusts the front end.
So the database runs the query
and returns the results to the front end application,
which might be a list of everyone
who has requested that white paper.
Now, if there was output validation,
the only thing the application could return
to the user would be,
thanks for requesting the white paper,
or information not complete,
or please enter again, right?
Just a few very discreet things.
But if there's no output validation,
whatever the database returned to the application
can be returned to the user,
or in this case to you, our attacker.
So the application presents the results to the attacker,
and that is a very simple illustration
of a SQL injection attack.
Next let's look at cross-site scripting.
Cross-site scripting has two versions,
persistent and reflective.
In a persistent cross-site scripting,
the goal will be for the attacker
to identify a vulnerable webpage
that their victims go to,
because ultimately what they want is a script
that's going to execute in the victim's browser.
So the attacker is going to identify a vulnerable webpage.
The attacker will inject a malicious string
or script into that webpage.
The victim clicks on the URL
and injects the script into the webpage.
The webpage sends that script right back to the victim.
The script downloads and executes
in the victim's browser and voila,
the victim's system is compromised.
The once again, right, if we had input validation,
the attacker in both the reflective
and the persistent would never be allowed to
inject that script into the webpage.
Next up is CSRF,
or cross site request forgery.
In this case, the attacker is going
to forge a malicious request
and embed it in a hyperlink with the goal
of exploiting the trust that a site has in a browser.
So the attacker is going to send the request
to a user logged into a targeted website.
The user clicks on the hyperlink
which sends a request to the targeted website.
Now how could that happen if they're already logged in?
Well, probably in a popup
would be one of the most common ways,
the user is already logged in.
A popup occurs,
click here to do our survey.
Say yes or no.
They click that, right?
That sends the request to the targeted website.
The website validates the request is coming
from the trusted sender.
The website executes whatever the malicious request is.
And again, we've got a compromise or a malicious outcome.
So it's important that you can recognize
injection, cross-site scripting,
cross-site request forgery, and directory traversal.
And recognize that really the foundation of all of those
is having weak or insufficient
or even non-existent input and output validation.
All right that my friends takes us
to a three second challenge.
Are you ready?
The process of validating the output of a process
before it is returned to the recipient.
One, two, three.
That's gonna be output validation.
Number two.
An attack that uses dot-dot-slash sequences.
One, two, three.
That's gonna be a directory traversal.
Number three, injection of a malicious code
into a vulnerable web application that will execute
in a victim's browser.
One, two, three.
That's gonna be persistent cross-site scripting.
Number four.
Tricking an application into including unauthorized commands
in the data sent to an interpreter.
One, two, three.
That's injection.
And lastly, number five.
Injection of malicious code into a web application
that initiates at the client side
and ultimately executes in the victim's browser.
One, two, three.
And that's gonna be reflective cross-site scripting.
All right, let's do a security-in-action together.
Put that knowledge into play about injection.
The results of a security assessment
for your organization's pre-production website
documents injection flaws.
The outsourced website developers
are minimizing the finding.
Ah, not such a big deal.
The marketing department's pushing really hard
to get this site published ASAP.
The website owner, claims she has no budget
to address any problems.
Matter of fact maybe they're already over budget.
Executive management turns to you
and is asking you for guidance.
What are you gonna tell them?
So we got this security assessment done
on this pre-production website.
So the website's not out there yet.
And it says, oh man you got some injection flaws.
So we go to the developers and the developers say,
oh, nah that's not a big deal.
They're really minimizing the finding.
But the marketing department says, listen, we're late.
We gotta get this out ASAP.
The website owner says I've got no money,
I have no budget whatsoever to fix this problem.
Management says what do we do?
So put me on pause, jot down some notes,
come on back with your response when you're ready.
Well, injection is a really serious flaw that can result
in unauthorized access, data exfiltration,
and data corruption.
And the business impact can be really significant.
Reputational, financial, and compliance damage.
So we wanna start with really emphasizing
that to management.
It is the responsibility
of the website developers to deliver secure code.
It's sort of inherent in the relationship.
But hopefully this was specified in the contract
because if it wasn't they perhaps are
gonna charge you more to fix it.
The bottom line,
doesn't matter that we're behind time or over budget.
The site should definitely not go live
until this flaw is addressed.
Again, because the business impact of unauthorized access,
data exfiltration and data corruption is really significant.
Reputational damage, financial damage,
and potentially compliance damage.
So you wanna do everything you can
to convince executive management to say absolutely not.
And you probably wanna point out
that wait a minute, we went through
the process of doing a security assessment
just to find out these kind of things.
Why wouldn't we pay attention
to what our security assessment is saying?
That's the reason we did a security assessment.
So having this very convincing conversation or discussion,
definitely my friend security-in-action.
You know it's not a very big word cloud
but there's a lot here.
And make sure that you really understand each
of these type of attacks.
When you're ready, come on over to the next lesson.
I'll be waiting for you.