Instructor: In this lesson,
we will learn about injection vulnerabilities.
Injection vulnerabilities occur when an attacker
is able to inject malicious code into a system
through an input field or other interface.
Specific injection vulnerabilities
include command injection, code injection,
cross-site scripting, cross-site request forgery,
server-side request forgery, and deserialization.
Command injection occurs when an attacker
exploits vulnerabilities in a system to execute
arbitrary commands on the host operating system.
Code injection involves inserting malicious code
into a vulnerable application,
which is then executed by that application.
An SQL or SEQUEL injection attack occurs when an attacker
inserts malicious SQL commands into a database query
for the purpose of manipulating the database
to execute unauthorized actions,
altering or deleting records,
or even gaining administrative control over the database.
Cross-site scripting abbreviated as XSS occurs
when an attacker injects malicious scripts into web pages.
Next, cross-site request forgery or CSRF attacks
involve manipulating a user into performing actions
they did not intend,
abusing the trust between a client and a server.
Next, a server-side request forgery or SSRF
allows an attacker to force a server
to make unauthorized requests
to internal systems or external resources,
abusing the trust between a frontend server
and a backend or internal resource.
Finally, deserialization attacks occur when an attacker
injects malicious data into an application
that processes the data by converting it
from a serialized format back into its original object form
to execute harmful code embedded in the data,
leading to remote code execution,
privilege escalation, or data corruption.
Let's learn more about commanded injection,
code injection, cross-site scripting,
cross-site request forgery,
server-side request forgery, and deserialization.
Then, we'll conduct a demonstration
of stored cross-site scripting.
First, we have command injection.
Command injection is a vulnerability
that allows an attacker to run arbitrary commands
on the host operating system
by exploiting flaws in an application.
When an application takes user input
and inserts it into a system command,
it can unintentionally allow malicious commands
to be executed if proper validation
and sanitization are not in place.
This can give attackers access to system level functions,
enabling them to read or modify files,
alter system settings, or compromise sensitive data.
A successful command injection attack
could even let an attacker gain unauthorized access
to other parts of the network.
Since command injection interacts
with the host operating system,
the potential impact is extensive.
Attackers might use this vulnerability to open back doors,
escalate privileges, or execute denial-of-service attacks,
effectively disrupting normal operations.
In the worst cases, command injection could allow attackers
to fully take over the system, leading to data breaches
and severe loss of control over the infrastructure.
So, command injection underscores the need for applications
to strictly validate and sanitize all inputs,
particularly those that interact
with underlying operating systems.
Coming onto the screen now is an example
of what a command injection might look like in a log.
In this example, the application is intended
to execute a simple ping command to diontraining.com
based on the user's input.
That's its design and function.
However, an attacker has manipulated the input
by injecting the semicolon rm -rf,
and then a file path to important data.
This has been inserted
after the initial and legitimate command.
The rm -rf command is used to forcefully delete files
or directories on Unix-based systems,
making it highly destructive.
In another example,
the following could be put into the ping application.
This example on the screen now
would ping diontraining.com
and then execute a second command,
which starts up a Bash shell with the /bin/sh
and then redirects it via a pipe over to Netcat
at a domain called hacked.diontraining.com through port 443,
which would be set up to receive
the shell Netcat is delivering.
This would essentially give
a full interactive command line access to the web server.
As stated earlier, you can prevent command injection
by conducting proper input validation
on input received from any user.
In the case of this web application,
it should only accept IP addresses or domain names as input.
Additionally, it should only allow IP addresses
or domain names to be pinged using the application
and anything after dotcom should be ignored or stripped
before sending the user's input to the ping command.
Second, we have code injection.
Code injection involves the insertion
of malicious code into an application,
which is then executed by that application.
Typically with the application's permissions.
This type of injection can occur when an application
dynamically includes user input
as part of the code it executes.
If proper input validation is not applied,
attackers can insert their own code, potentially hijacking
the application's intended functionality.
So, code injection can compromise data security,
expose confidential information,
or lead to unauthorized actions,
often allowing attackers access
to sensitive application functions.
In contrast, command injection
directly executes system commands on a server,
while code injection affects only the application behavior.
Therefore, code injection typically needs to be conducted
in the same programming language as the application.
A successful code injection attack
can disrupt normal operations, modify or delete records,
and potentially grant attackers access
to underlying resources or other applications
connected to the system.
But it does not offer direct access
to the host operating system like command injection does.
But because code injection
often exploits weaknesses in the application layer,
it can allow an attacker to bypass
other security controls like firewalls.
So again, sanitizing input
and avoiding dynamically executed code
that includes user input can mitigate code injection risks.
Coming up on the screen now
is a simple example of code injection.
Imagine a web application that lets users enter their name
to create a personalized greeting.
We can see this in the code.
If the application directly embeds the user input
into the code without validation,
an attacker could manipulate it.
In this example, in the user input section,
the first line of code attempts
to list files in a server directory
instead of just printing the greeting.
It's done this way because the user
has provided input to use the os.system command
and the ls.command within a shell.
This demonstrates how dangerous it can be
to execute user input as code.
Preventing these risks involves properly validating inputs
and avoiding functions that evaluate raw user data directly,
such as the EVAL function,
which was used in the previous example.
Third, we have cross-site scripting.
Cross-site scripting comes in three main types.
Reflected, stored, and DOM-based cross-site scripting.
Each type has distinct characteristics and attack methods,
but all rely on the failure of input validation,
and have the potential to cause significant security issues
by injecting malicious scripts
into a vulnerable application.
Reflected cross-site scripting occurs
when an attacker injects a script into a URL or form,
which is executed and then referenced back to the user
without proper validation or sanitization.
This attack is typically delivered through phishing links
where an unsuspecting user
clicks on a URL containing the injected script.
The script then executes in the victim's browser,
allowing the attacker to steal sensitive data
such as session cookies or personal information.
Since the attack is not stored on the server,
it is only active for the user
who interacts with the specially crafted link.
The following is an example
of reflected cross-site scripting
in a vulnerable search functionality
that displays the search query
back to the user without validation.
In this attack, which is partially displayed on the screen,
the user will have clicked on a link that contains a query
with a script alert, "You have been hacked!"
and then close script tag.
This would display an alert
when the user clicks on the link.
This is reflected cross-site scripting,
executing a script by reflecting unsanitized input
back to the user.
Next, stored cross-site scripting injects a script
saved on the server to any user
who renders the infected page.
In a stored cross-site scripting attack,
attackers inject malicious code into fields like comments,
forum posts, or a profile information,
which is stored in the applications database
and is executed by any user who visits the page.
This type of cross-site scripting
can reach a large number of users,
and is often more to detect and fix
as the payload persists across sessions.
For example, if a social media platform
fails to validate or sanitize user-generated content,
an attacker could post a comment
containing a malicious script.
Each time users view the page the malicious script is on?
The script executes in their browsers,
stealing session tokens,
or redirecting them to phishing sites.
Finally, DOM or document-object
model-based cross-site scripting
occurs when the malicious script is executed as a result
of modifying the document object model on the client side.
This attack relies on vulnerable client-side JavaScript code
that dynamically generates content based on user input.
In a DOM-based cross-site scripting attack,
no data is sent to the server.
Instead, the attack manipulates the structure
or content of the webpage within the client's browser
affecting that client and that client only.
DOM-based cross-site scripting is more challenging to detect
because it resides entirely on the client's side
and doesn't leave traces in server logs or databases.
For instance, a DOM-based cross-site scripting vulnerability
might arise if a JavaScript function reads from the URL
and inserts it directly into the webpage.
In this scenario, an attacker could craft a link
with a script injected into the URL parameters,
causing the victim's browser
to execute the script upon loading the page.
To prevent DOM-based cross-site scripting,
developers should avoid using
potentially dangerous functions like innerHTML
or document.write with user-supplied data.
So, each of these cross-site scripting types
highlight the importance
of thoroughly sanitizing user input, encoding output,
and utilizing content security policies
to limit the execution of untrusted scripts on web pages.
Now for the exam, if you encounter a log snippet
or captured URL with script tags or any kind of JavaScript,
it likely indicates a cross-site scripting attack.
Next, if you see something with documentdot something,
like document.cookie or document.write,
this likely indicates a DOM-based
cross-site scripting attack as it affects
the browser's document object model.
Keeping these tips in mind will help you identify
cross-site scripting attacks accurately on the exam.
Fourth, we have cross-site request forgery.
Cross-site request forgery or CSRF is an attack
that tricks authenticated users into performing actions
they did not intend on a web application
where they've already logged in.
By exploiting the trust a server
has for a client or authenticated user,
CSRF sends unauthorized requests
that appear legitimate on the client's behalf,
effectively using the user's session
to carry out actions without their consent.
For example, in an online banking application,
a CSRF attack could initiate a fund transfer
or perform other critical actions
without the user's knowledge.
Since the request originates from a client
in an active session,
the server has no reason to question the request.
So, it's processed, potentially compromising data integrity,
user privacy, and overall security.
So, effective session management is crucial
for preventing cross-site request forgery
as it allows applications to track user actions
securely across sessions,
often relying on cookies or tokens.
However, predictable or insecure session tokens
can make these attacks easier for attackers to exploit.
This is because if an application generates tokens
in a predictable manner,
attackers can analyze patterns to guess a valid token,
allowing them to forge requests that appear legitimate.
Similarly, if a session token
is transmitted without encryption,
attackers can intercept it over the network
and use it to send requests as an authenticated user.
So, to mitigate cross-site request forgery risks,
applications commonly implement anti-CSRF tokens
that are unique to each session
and validate each request to ensure
it was initiated by the authenticated user.
Additional measures like re-authentication
for critical actions
further limit cross-site request forgery attempts
by requiring confirmation from the genuine user.
Fifth, we have server-side request forgery.
Server-side request forgery or SSRF
exploits a server's ability to make requests
to external or internal resources
on behalf of the application
running on the application server.
In a server-side request forgery or SSRF attack,
attackers trick the application server
into fetching data from unauthorized backend locations,
potentially accessing internal systems
or restricted network segments.
For example, by abusing trust
from a frontend application to a backend resource,
attackers can gather sensitive information
about the internal structure of a network,
which could serve as a foothold for more extensive attacks.
So, the implications of server-side request forgery attacks
can be significant, especially in cloud environments
where services are closely interconnected.
An attacker in a cloud infrastructure
could exploit server-side request forgery
to retrieve metadata from cloud servers,
accessing internal management interfaces,
or even to manipulate a server
into executing unauthorized actions
on sensitive backend systems.
Proper input validation.
Limiting allowable destination addresses
and enforcing strict access control on server requests
are good defenses against server-side request forgery.
Sixth and last, we have a deserialization.
Deserialization attacks take advantage
of the deserialization process where data has been converted
into a structured format for storage or transmission,
and is transformed back from deserialized format
to its original object form within an application.
When an application deserializes untrusted data
without proper validation,
an attacker can inject malicious content
into the serialized data.
During deserialization, the application
may inadvertently execute harmful code
embedded in this data,
allowing the attacker to execute remote code,
escalate privileges, or corrupt application data.
A successful deserialization attack
can severely compromise an application security,
potentially granting attackers access to sensitive data
or control over core application functionalities.
In severe cases,
attackers may use deserialization vulnerabilities
to install persistent threats, open back doors,
or even take control of the application server.
To mitigate this risk,
applications should avoid deserializing untrusted data,
use serialization formats with built-in security controls,
enforce strict input validation,
and implement secure coding practices,
such as restricting the types of objects allowed
during deserialization.
Okay, I know this is a long lesson,
but I would like to take the time to show you
what stored cross-site scripting looks like.
So, let's do a demonstration.
In this demonstration,
I'm going to use a Google cross-site scripting game.
I've already completed the first stage of this game,
so you can see that I'm on Level 2
called Persistence is the Key.
We have a mission description and a mission objective.
My objective in this application
will be to use stored cross-site scripting
to pop up an alert every time someone reloads this page,
simulating every time the page is rendered
by somebody coming to this application.
Right below this, we have the application
that we will be manipulating.
This looks just like a message board
and it has a place for me to share some status.
So, I'm going to go ahead and share some status.
"Hello, this is great!"
Let me go ahead and share it.
And you can see that my comment
now exists on this message board.
If somebody else were to come and visit this message board,
simulated by me refreshing the page,
you can see that my comment still exists here on this page.
So, if there is no input validation,
an attacker could enter code using this same message process
and have it executed every time someone visits this page.
So, we're going to enter in the following code.
This code will attempt to load an image with image source.
Then it expects to get a path
for the file location of that image.
In this case, I'm just writing the word FAKE.
There is no image that I'm trying to load,
so I know there's going to be an error.
When that error occurs, I'm telling it what to do.
I'm telling it to use that JavaScript alert function
to pop up an alert box on my screen.
This is going to demonstrate
stored or persistent cross-site scripting.
Meaning that every time someone visits this page,
this malicious code right here is going to be executed.
So, let's give it a shot.
I've shared the status. There it is right there.
You can see the alert box that popped up on my screen.
And when we look at the message board itself,
it just looks like a broken image.
Of course it does.
I told it to load up an image
and then gave it a fake file path.
Now, let's see what happens
when someone else comes to this message board.
We'll simulate that by clicking the Refresh button.
Sure enough, every time someone visits
and renders this page,
that script executes on the background,
So, that script is stored on the server,
making this stored or persistent cross-site scripting.
This is the end of our demonstration.
So remember, injection vulnerabilities allow attackers
to insert malicious code into an application
through input fields or interfaces,
compromising system integrity and security.
Command injection enables attackers
to execute commands directly on the host operating system
while code injection inserts code
into the application itself,
often hijacking its functionality.
Next, cross-site scripting exploits vulnerable webpages
by embedding scripts that run in user's browsers.
Whereas cross-site request forgery tricks users
into unknowingly performing actions
while logged into a server,
exploiting the trust between the server and the client.
Next, server-side request forgery takes advantage
of a server's ability to make requests to a backend resource
that trusts them, potentially exposing internal systems.
Finally, deserialization attacks and manipulate
the process of reconstructing data from its storage
or transmission format to execute harmful code,
risking remote control and data corruption.