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 back end 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 username and password.
Maybe it's a search block where you're doing a search query.
Maybe it's just someplace where you're typing in information for an email or a 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 an interpreter,
i.e. 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 has snuck into your system and
then tracks through your browser to then perform the action that the malicious actor wanted to utilize.
This is known as cross-site scripting.
It's providing that two way information between the server and your browser that the threat actor is
utilizing to execute code, than 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 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 changed that link into something that it shouldn't be, i.e. 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 first one is an HTTP referrer.
A referrer is where the header serves as the means of verifying the source of the request.
This aids in ensuring the original request and the expected sources, meaning that the referrer 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 going to be strict with our cookies?
Are going to be lax with our cookies.
How are we going to provide a defense against this?
By preventing the transmission of cookies within different injection attacks, we can use a Captcha
where we 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 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 where 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 going to compare that based on your submission.
And if it compares and contrasts properly you're good to go.
We can do a user authentication 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 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 Lies a defence 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're 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 addition.
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 pre-written 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'll 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 bake 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 site of the malicious action and 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 another
server, this occurs when a server does a malicious action 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 ones as well.
We want to do input validation, where we validate users inputs to ensure that the URLs or the scripting
is validated.
We don't want special characters.
We don't want language that looks or adopts 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 release privilege, where only you 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 going to 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 URLs by removing potentially malicious
characters and validate that they are exclusively referenced and expected host of an IP address.
Of course, we're going to use 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 a reverse proxy and we want to have some process of isolation when we're going through
in creating our server 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 onto 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 little code in there and instantly rise to level
60 without any kind of, uh, 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're going to use secure coding web application firewalls.
We're also going to make sure that our file handling libraries are correct and that they've been validated.