Time
9 hours 31 minutes
Difficulty
Intermediate
CEU/CPE
10

Video Description

This lesson teaches participants about the OWASP definition for the A1 Injection. Participants learn how an LDAP injection occurs and about different security weaknesses and injection flaws. In code, it is easy to discover injection flaws. This course section also discusses the different kind of injection attacks, not limited to but including the following: • Command/OS Injection • SQL Injection • XPath Injection • JSON Injection • LDAP Injection Participants also learn about an SQL Injection Code Sample, which helps to discover where a vulnerability exists. Finally, the instructor offers an example of CERT Secure Coding Standard using a Java example that is non-compliant.

Video Transcription

00:04
Hello and welcome to secure coding course. My name is Sonny wear and this is Theo. A loss top 10 for 2013 a one injection category
00:15
now first going to take a look at the A loss definition for a one injection. It states the following injection flaws Such a sequel operating system, otherwise known as command and L dap injection, occur when untrusted data is sent
00:34
to an interpreter
00:35
as part of a command or query
00:39
the Attackers. Hostile data can tricked the interpreter into executing unintended commands or accessing unauthorized data.
00:50
Now, if we take a look at the old boss chart,
00:52
we can see that the attack factors here have an exploit ability of easy.
00:59
This is good news for us.
01:00
The technical impacts, however, can be very severe, particularly when it leads to a data breach.
01:10
Now let's take a look at what a wasp *** to say about the security weakness itself. Injection flaws occur when an application sends untrusted data to an interpreter
01:23
well, more like the attacker is sending it right.
01:26
Injection flaws are very prevalent, particularly in legacy code often found in sequel queries. L DAP queries Ex PATH queries OS commands program arguments, etcetera.
01:40
Injection flaws are easy to discover when examining code,
01:45
but more difficult via testing.
01:47
Scanners and fathers can help Attackers find them.
01:52
And, I would add, could also help us as programmers to find them a swell.
02:00
Now there's a plethora of different types of injection attacks. I'm labeling some here but realize that there are many more.
02:10
So we will take a look at command, otherwise known as operating system injection
02:16
sequel Injection otherwise known a sequel I
02:21
Ex Path Injection. Jason Injection will actually have a demo of Jason Injection
02:27
and L DAP injection
02:30
now first sequel injection.
02:31
So here is where an attacker is going to inject a sequel statement, usually inside of a text box, but could also be done as a parameter somewhere else.
02:46
When that sequel statement is received by the Web server,
02:52
there is a lack of validation in the application code on the server side.
02:59
And so what happens is that sequel is actually received
03:04
and executed by our database,
03:07
and so
03:08
this is an unintended execution. If we take a look at an example, we can see that this is an arbitrary construction by an attacker
03:20
to allow for an unintended execution of a sequel statement by the database. Let's take a look at this statement. It says Select star from Users Table, where name is equal to Joe or one equals one dash, dash and password equals whatever.
03:38
Now the first thing to notice
03:40
is that there's an or statement following Joe immediately after this or statement
03:46
is one equals one.
03:50
Now the one equals one attack, basically, is any kind of totality of truth,
03:57
meaning that so long as the statement equals true,
04:00
it can be used in this type of attack.
04:04
The Dash dash is a way to comment out the remainder of the statement, and this is usually going to be sent tactically specific to the type of sequel database
04:18
that is being run on the back in.
04:21
So sometimes Attackers will
04:25
purposefully put in a sequel injection attack, hoping to receive some sort of
04:31
error message that indicates the type of database that's actually running That helps them to construct or craft their sequel statement. Better specific to that type of database, whether it's Oracle or my sequel, et cetera.
04:48
So the result of this query when executed where a sequel, vulnerability exists
04:56
is that it will divulge full disclosure from the user's table of all the users I. D. S and their passwords.
05:05
Now we're looking at the same attack on Lee as it's entered inside of the text box, and you can see that for my name. I am ending my name with the tick and then we have that or statement. And then we have our two totality of truth, which is one equals one,
05:25
followed by a dash dash, which is our comment now, in the case of my sequel, after the two dashes, we actually have to put another space.
05:34
And so you're going to see in the demo that this will actually divulge all of the contents of the user's table.
05:44
Now, command injection is of a similar nature, but this usually occurs due to the immediate execution of arguments received.
05:55
This is where we receive something either a targ subzero arcs of one etcetera.
06:01
And we just immediately passed that perimeter into our executive command or eggs ical function. The problem is that
06:13
maliciously, an attacker could place a command that will allow the attacker
06:21
to have escalated privilege on the on the actual machine where
06:28
the command is being executed.
06:31
Now the case study is on Sony PlayStation.
06:35
Sony, of course, was hacked in this instance back in 2011
06:41
and the rumor has it that they were actually owned by a version of the one equals one sequel, Injection Attack.
06:51
And so you can read more about the history of that at the link below.
06:57
Now for the sample code, we're going to take a look at
07:01
one of the CERT standards, and
07:05
because injection is just so large, it's such a very, very large category.
07:14
It's difficult to focus on any one particular type of injection,
07:19
so we're going to just stick with looking at the receiving of untrusted data and how we can protect our application from that data.
07:30
So in this example, we have
07:32
exclude unsanitized user input from format strings.
07:39
Now, without reading to you the fine print of this particular rule
07:44
we basically have in the package. In class of Java I au Prince stream to formatting methods format in print, F
07:56
now realize that system out and system air our print stream objects that air very commonly used across Java applications.
08:07
The point here is that If untrusted data is incorporated into a format string, it can actually result in information leakage. We're going to see an example of that in a moment.
08:20
Inflict validation needs to be added in our code in order to ensure that we are
08:26
Onley, receiving acceptable values and not interested data.
08:31
So let's take a look at an example.
08:33
So if we take a look at our sample code here,
08:37
this is a non compliant code example that can leak information about the user's credit card specifically about the expiration date in this particular code snippet.
08:52
Now let's go ahead and take a look at the code.
08:54
So we have this class format and inside, we have
09:00
a static instance of the Gregorian calendar. Now what's being simulated in this state is theatrical expiration date,
09:11
and so
09:11
there's a receiving in of parameters at Argus sub zero,
09:18
and whatever is received in is actually being compared to this date.
09:24
So in the main method,
09:26
it says, the are subzero should contain the credit card expiration date, but it might contain percentage $1 sign.
09:37
This is the month,
09:37
the day or the year format. Specify IRS,
09:43
and if that's the case we run into information leakage.
09:48
Now here we have our system out. Remember, that's our prints. Stream class. That's an instance of the prince stream class
09:56
and there is thief format method that we were warned about.
10:01
Now what it's displaying out is whatever is received in the arts sub zero
10:09
parameter.
10:11
And the problem with that
10:13
is that the attacker could supply the percent $1 sign tm
10:20
for that argument parameter
10:24
and if so, it will actually display what we have being stored for our month. So in order to address this problem, what we need to do is exclude any untrusted user input from that format string.
10:41
And although our subzero still may contain some sort of attack or some sort of payload with a format specify WR
10:52
because we're no longer allowing the display of arc subzero
10:58
it, we basically render that payload attack is being inert.
11:03
Okay, so we have the same code here,
11:07
but the only thing we've changed is now in that format method of our system out.
11:13
We on Lee display percent s,
11:16
So whatever gets passed into our subzero
11:22
is actually then displayed via the percent s format
11:28
instead of being displayed directly as whatever was presented
11:35
in this parameter.
11:37
And so even if our attacker were to supply something
11:41
that would cause information leakage, such is this percentage $1 sign month.
11:48
The result would just echo back that exact
11:54
exact same value instead of leaking the month as it did before.

Up Next

Secure Coding

In the Secure Coding training course, Sunny Wear will show you how secure coding is important when it comes to lowering risk and vulnerabilities. Learn about XSS, Direct Object Reference, Data Exposure, Buffer Overflows, & Resource Management.

Instructed By

Instructor Profile Image
Sunny Wear
Instructor