Preview
Video Player
00:00
00:00
Injection
10:55Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
[MUSIC]
0:00
Welcome back.
0:04
To begin our discussion of
the OWASP Top 10 we're going to
0:05
start with command injection, the number
one vulnerability according to OWASP.
0:08
Injection flaws occur when untrusted
data is sent to the browser or
0:13
app as part of some input,
which is usually a command or query.
0:17
When this occurs, the attacker's
data can cause the application
0:21
to execute commands without permission.
0:24
This permission should be given by
the developer or the application.
0:27
This could cause an access to user
data without proper authorization or
0:30
even the ability to completely
bypass authentication.
0:34
We'll break down injection
into two categories,
0:38
service side code injection and
database injection.
0:41
First, we'll look at server
side JavaScript Injection.
0:44
Server side JavaScript injection can
impact an application when functions such
0:47
as eval(), setTimeout(),
setInterval(), and
0:52
Function() are use of
process user provided inputs.
0:55
They can be exploited by
an attacker to inject and
0:58
execute malicious JavaScript
code on the server.
1:01
Okay, it's possible for malicious users
to execute code in the server, but
1:04
what about the client?
1:08
That's a great point, and that's
an entire category of injection attacks,
1:09
called cross-site scripting,
which we will address in the next video.
1:13
In the meantime, let's continue to
discuss server-side JavaScript injection.
1:16
Web apps using the JavaScript eval()
function that parse incoming data
1:21
are vulnerable when user
input is not validated.
1:25
Without sanitizing the data,
1:28
an attacker can inject any data
they want into the application.
1:30
This data then will be
executed by the server.
1:34
The setTimeout() and
1:36
setInterval() functions are also
vulnerable without input sanitization
1:37
since their first argument passes
the user input to the eval() function.
1:41
A potential attack this could cause
is a denial of service attack.
1:45
A denial of service attack allows an
attacker to bring down a web application
1:49
by finding a place where user input is not
sanitized, and then injecting a command
1:53
that would cause the server
resources to be used completely.
1:58
For example, an infinite while loop
that would be run by the server-side app
2:01
could be injected using the eval()
function or related functions.
2:05
In this case, the input would cause
the node.JS event loop to use 100% of its
2:09
processor time, and it would be unable to
handle any other innocent users' requests.
2:14
In other languages, similar actions can
be taken, causing the same effects.
2:19
Now, let's take the first
look at the application
2:23
we will use throughout this course.
2:26
This application comes from OWASP, and
shows in detail how nearly all of the top
2:28
ten vulnerabilities can occur in
a JavaScript and node.js base application.
2:32
The application we will use is
a human resources application
2:37
that allows company employees to adjust
various parts of their compensation
2:41
from benefits to investment contributions.
2:45
The compromise of a user's personal
401K data would be very, very bad, and
2:47
we'll see how things just like that
can happen as we explore the top 10.
2:52
We're logged into our application, and
2:57
we see we have a lot of
different functionality here.
2:59
We have a dashboard, which we're on now,
a contributions page, an allocations page,
3:02
and a profile page.
3:07
Lets now go to the contributions page.
3:08
On the contributions page, we see that
we can enter a contribution of different
3:11
types as a percentage on
the right side of the table.
3:14
Then we're able to submit it
by clicking the Submit button.
3:17
As we just discussed, when application
passes user input to certain JavaScript
3:20
functions like eval(), this can be
executed by the server if not sanitized.
3:24
By looking at the source code for
this form, we see that the developer
3:29
used the eval() function to convert
the user supplied input to an integer.
3:32
On that note, let's try to bring down
the application by killing the backend
3:36
node.js process by entering the kill
command into this percentage field.
3:41
Since the server uses an eval() here
to parse the contribution user input,
3:45
then bad things might happen.
3:49
Wow, that's bad.
3:52
What about accessing files?
3:54
We can also do that.
3:56
This command uses the NodeJS file
system library to read the current
4:11
directory's files.
4:14
And then, it prints them out.
4:16
Now, if an attacker uses this, they can
have access to any of our server's file,
4:17
like the one seen here.
4:21
If we store data we shouldn't have been
storing there, they would also get that.
4:23
Now, how do we prevent
server-side injection?
4:27
In general, the simplest fix is to
validate user input before processing.
4:30
You will find that this tip is given
almost everywhere within web security.
4:34
Always sanitize user input.
4:38
Other strategies include not using
the eval() function to parse user input,
4:41
as well as not using setTimeout(),
setInterval(), or function.
4:45
When parsing JSON user input,
rather than using eval(),
4:49
you can use the JSON.parse method and
the parse integer and related methods for
4:52
converting types rather than using
a function that executes arbitrary code.
4:56
Finally, include the use strict
declaration at the beginning of
5:01
a file or function.
5:04
This enables JavaScript's strict
mode within the selected scope
5:05
restricting many of these issues.
5:09
To fix this vulnerability,
5:11
we can go back to the source
code in the contributions file.
5:13
Now, instead of using the eval function
to parse input, we instead just use
5:16
the parseInt function to safely
parse the contribution percentage.
5:20
If there is an error or bad input is
passed, it'll just refuse to process it
5:23
The next major type of injection we'll
discuss is injecting commands into SQL or
5:37
NoSQL databases, such as MySQL or MongoDB,
5:42
otherwise known as SQL injection or
database injection.
5:45
SQL injection has been responsible for
many major attacks and
5:50
breaches in the web's history,
including Yahoo,
5:53
which had 450,000 plain
passwords stolen in 2012, and
5:57
Equifax with 145 million people
affected by stolen data in 2017.
6:01
For a list of real world
SQL injection flaws and
6:05
their effects in recent history,
check the teachers notes for
6:09
the link to a website showing many
historical and recent flaws of this kind.
6:11
Now, back to how this actually works.
6:16
SQL and NoSQL injection allow an attacker
6:19
to inject code into a database query
that will be executed by the database.
6:22
These flaws occur when developers
use dynamic database queries, or
6:26
in other words,
queries that take user input.
6:31
For example, this could be a search
field where the user's data
6:34
is put inside the query
without sanitization.
6:36
Keep in mind, both SQL and
no-SQL databases are vulnerable.
6:39
Now, let's dive into real cases
of both SQL and NoSQL injection.
6:43
Here, we have an SQL statement used to
authenticate a user with a username
6:48
and password.
6:52
In this statement, if the statement
is not properly constructed,
6:54
an attacker can supply malicious
input through the username field.
6:56
With this input,
7:00
the admin user account can be accessed
without needing the password.
7:01
The attacker can then cause the query
to be interpreted as this new query.
7:05
Here, because the username
parameter is admin, and
7:09
the password has been commented out with
SQL's comment syntax, the database will
7:12
most likely return the full user profile
of the admin user, including the password.
7:16
Now, how do we prevent SQL injection?
7:21
Well, when your application uses
standard SQL via database such as MySQL,
7:25
the best way to prevent SQL injection
is to sanitize user input and
7:29
use prepared statements
in your native language.
7:33
Prepared statements avoid
the vulnerabilities, and using string
7:36
concatenation to form SQL queries, and
they apply input sanitization to the data.
7:39
Most modern database frameworks,
like Django and
7:44
Ruby on Rails,
use prepared statements by default.
7:47
Let's move on to NoSQL Injection,
which occurs when the attacker exploits
7:50
databases with non-standard
SQL-like queries, such as MongoDB.
7:54
The equivalent of the unsafe query
we saw with SQL, except now for
7:59
NoSQL Mongo DB database looks like this.
8:03
While here, we're no longer dealing
with the standard SQL query language,
8:07
an attacker can still achieve
the same results as the SQL injection
8:11
by maliciously using built-in
Mongo DB parameters.
8:15
In MongoDB, the gt, or
greater than parameter,
8:19
selects the documents when the value of
the field is greater than supplied value.
8:21
If a string is passed,
it is the numerical value of that string.
8:25
In this statement, this means the password
field is compared with the empty string.
8:29
And since we know that the password
will likely not be empty,
8:33
its value will be greater
than supplied empty string.
8:37
Uh-oh, this means the database
will return true here.
8:39
Now, we've caused the original
find command to return the admin
8:42
user's information.
8:45
Other parameters can also be used.
8:47
Check out the teacher's notes for
8:49
several links exploiting MongoDB databases
when user input is not sanitized.
8:51
In our application,
8:55
the allocations page is vulnerable to
NoSQL injection when running searches.
8:56
This allows an attacker to retrieve
allocations for all users in the database.
9:01
Let's see it in action.
9:05
Let's check out the Allocations page.
9:07
On the Allocations page,
9:10
the user can see where their savings is
going in terms of investment accounts.
9:11
Here, the user can submit a threshold
value to filter allocations,
9:15
and an attacker can infer that this
field sends input to the database.
9:19
A skilled attacker might recognize that
this kind of filtering command could
9:22
possibly be interpreted by the database or
other storage engine.
9:25
So with that in mind,
9:28
let's try one of the NoSQL injection
attacks we saw earlier on in this field.
9:30
By ending the query prematurely,
we can return all the allocations for
9:34
every user in the system.
9:38
We do this by causing the query to return
true on the generic filter function,
9:39
which will give us the allocations for
all users and not just the logged-in user.
9:43
Let's try it.
9:48
Voila, it worked.
9:55
Preventing NoSQL injection can be
accomplished in many of the same ways as
10:01
preventing SQL injection.
10:05
The first step is to always
sanitize user input.
10:08
This means understanding what operators
and parameters will accept input, and
10:11
being aware of operators
which will execute code.
10:16
Similar to sanitizing user input, ensure
you are validating the types provided by
10:18
users before passing that
data to MongoDB queries.
10:23
Beyond sanitizing user input and
performing input validation, be careful
10:26
which users in your application are
assigned admin access to your accounts.
10:30
The compromise of an admin account
could lead to the compromise of other
10:34
parts of your app.
10:37
Try to minimize the privileges
of the operating system account
10:38
the database operator runs as,
or a compromise of the database
10:42
could lead to full takeover of
the server the app is running on.
10:46
This is known as the principle
of least privilege which pops up
10:49
all across the field of security.
10:53