Injection attacks are malicious actions by inputting
untrusted data into an interpreter for evaluation
where the system calls the operating system to trigger the execution of the script
or the external function or accessing backend data using a database language.
I know that sounds like French to me too.
What we're really saying here is inside each website,
you've got a place where you can put input information.
That information is usually your user name and password.
Maybe it's a search block where you're doing a search query,
maybe it's just place where you're typing in information for
an email or blog or even a forum post.
But all those places where you can inject information
allow for malicious actors to inject code or script,
which a malicious actor can then utilize to perform an attack.
That attack is known as an Injection attack.
And whenever a web application employs that interpreter,
ie how I utilize that data,
it processes that untrusted data making the use of the Injection attack,
which then allows somebody to click on it.
And that's where we get that Injection attack from the part
Injection attacks that inject malicious javascript into a
web application is then executed by other users.
This is known as a cross-site scripting
attack where the attacker uses malicious code or
javascript in this case to trick the
user's browser into performing an unwanted action.
So what are we saying?
Here, you click on something,
let's say that you're on a forum post and you love unicorns.
We'll just use unicorns.
So you love unicorns and there's a little picture of a unicorn on a forum
post and you want to click on it because you want to see it.
You want to blow it up.
Well, you click on that little thumbprint, it blows up the unicorn.
But what's really happening in the back end is that a malicious code is snuck
your system
and then tracks through your browser
to then perform the action that the militias actor wanted to utilize.
This is known as cross-site scripting.
It's providing that twoway information between the server and your
browser that the threat actor is utilizing to execute code.
Then by getting a response from your browser,
there are two types of cross-site scripting attacks,
persistent and non persistent within a persistent attack.
The website stores the code on the site,
it typically through a message board or that unicorn picture I was talking about
and the user unknowingly activates it by clicking on either
the code or the text or even the picture.
This is known as a persistent attack.
A non persistent attack also known as a reflected
cross-site scripting attack is a server software flaw.
This is where the server has a flaw with embedded within it.
And the malicious actor goes in and changes something
within the initial software or within the web page itself
to provide the attack structure.
So you click on something that was legitimate before,
but somebody took advantage of the server software and then change that
link into something that it shouldn't be ie making it malicious.
That's a non persistent cross-site scripting attack.
There are different mitigation strategies that
we can use for cross-site scripting.
And many of these are cross functional meaning across the board.
Many of these would be utilized not just for cross-site
scripting but for all Injection attacks as a whole.
The,
the first one is an HTTP refer a referer is where the
header serves as a means of verifying the source of the request.
This aids in ensuring the original request and the expected sources.
Meaning that the referer says, are you supposed to be here?
Is this something that I'm supposed to be doing?
And if so I verify you, we're good to go. If not, I don't think this is a good idea.
So I'm not going to do it
the same site attribute setting.
This is a setting within the same site attribute that takes cookies and it says,
are we gonna be strict with our cookies?
Are gonna be lax with our cookies?
How are we going to provide a defense against this by
preventing the transmission of cookies within uh different Injection attacks.
We can use a capsa
where we can identify different pictures.
So again, I'll use my unicorn reference because why not? Right.
And we can have all kinds of different pictures where it says, hey,
out of these nine pictures available,
pick all the unicorns and if you successfully pick all the unicorns,
it may provide more unicorns for you to pick on or
it may gain you access into the white site itself.
We have tokens,
these incorporate a unique token within each user request and
it provides legitimacy by validating the source against the server.
And it says everything checks out. You can then come into my website.
We can do protection frameworks within it which provides
safeguards and features against these types of attacks.
We can do a double submit cookie.
We're writing different cookies and we're saying, hey, resubmit this,
we're going to randomly generate this one cookie.
We're going to embed it into a hidden field and
then we're gonna compare that based on your submission.
And if it compares and tracks properly, you're good to go.
We can do a user reauthentication where we go through and say,
you know what I know that you authenticated once, but this is kind of sensitive.
Uh This provides some banking and information.
Why don't you go ahead and re authenticate again?
Just to verify that you are who you say you are.
We can do a web application firewall where we just utilize a defense in
depth strategy where the firewall goes in
and stops certain types of Injection attacks.
It provides a little bit
more robustness to our web applications and it's just
a technology feature you're probably already aware of anyway.
And then finally, we want to do software updates.
A lot of these flaws that we see within servers
and within sites themselves are simply need to be patched.
We are already aware of the flaws. The fixes are there.
You just literally need to go in and press that little button
that says let's upgrade our site to the newest edition cross-site request.
Forgery occurs when a malicious website, email, blog,
instant message or comparable program tricks the authenticated user's browser
into performing unwanted action on a trusted website.
So let's say that you go into a website or a blog
or even a website and you click on that little phishing email
you by clicking on that phishing email,
you've interpreted a script that then performs an action on your behalf.
That action could be telling your browser on the back
end to go to your bank account and transfer funds.
It's a prewritten script.
So a lot of times you may bank with Chase,
but the script is designed for Bank of America.
And so it doesn't work. It will still try to go to the Bank of America's website
and sign you in using your session cookies to authenticate your your browser.
But if you don't bank with Bank of America, no harm, no foul.
However,
let's say that you do bank with Bank of America by going through and
providing that script and clicking all the
right buttons and injecting your username password.
You could suddenly find that your entire bank account has been emptied out.
This is cross-site request forgery within cross-site scripting
or
XSS.
We're talking about the server side being
the attack platform under cross-site request forgery.
We're talking about the client or your browser
being the the side of the malicious action.
In cross-site request
forgery,
the client is utilizing malicious software or a malicious script to
interact with a legitimate server to process a malicious action.
The different techniques for mitigating cross-site request forgery are almost
exactly as they are the same for cross-site scripting.
There's really no change between the two server side request.
Forgery takes place much like cross-site request forgery
except the server is doing the request unlike
cross-site request forgery where it's the client performing
the malicious action against the other server.
This occurs when a server does a malicious act against
another server where a server which was legitimate in nature
where a user or an action on that server performed
a malicious script or malicious act against another legitimate server.
This is known as server side request,
forgery much like cross-site scripting and cross-site request forgery.
A lot of these things are the same However, there are some new
as well.
We want to do input validation where we validate users' inputs
to ensure that the URL S or the scripting is validated.
We don't want special characters.
We don't want language that looks or docks to be uh coding.
We just don't want to allow it.
We want to allow just the basics,
zero through nine uppercase and lowercase letters.
And when possible, we don't want those special characters.
We want to do least privilege where only you have only have access
to the amount of privilege within the network as you decently need.
That means that we're not going to have the janitor out
there having CEO access or access to server configuration files.
If someone leaves our it department and goes to a different department,
we're gonna go back through and say you don't need access to this anymore.
You just have least privilege.
We're going to do URL validation where we validate and sanitize the
LS by removing potentially amalicious characters and
validate that they are exclusively referenced,
an expected host of an IP address.
Of course,
we're going to secure coding to make sure that we go through and there's
no vulnerabilities in there that web application
firewall and the patching those haven't changed.
We're going to provide dedicated libraries where we're not going through github
or some other third party website that's unverified
to provide those libraries for our coding.
We want to use dedicated verifiable validated
libraries when we're doing our coding,
we also want to do reverse proxy and we want to have some
process of isolation when we're going through
in creating our search software directory.
Transversal is a web application server that allows an attacker to
gain unauthorized access to restricted directories
and files within the subdomain.
That means that you interact with a website and
it's giving you permission to access certain directories or
files that normally you just wouldn't have access to
and shouldn't have access to through normal means.
This would be like me going on to a web
application playing a video game and going in and saying,
you know what, instead of being level 20 I'm just going to put this
code in there and instantly rise to level
60 without any kind of validation or authentication
and allowing myself to instantly gain that information and
change the code of the actual game itself.
This is known as directory traversal.
Again,
a lot of the same mitigation strategies are going
to be utilized as we've already discussed before.
We do use secure coding, web application firewalls.
We're also going to make sure that file handling
libraries are correct and that they've been validated.