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
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
as part of a command or query
the Attackers. Hostile data can tricked the interpreter into executing unintended commands or accessing unauthorized data.
Now, if we take a look at the old boss chart,
we can see that the attack factors here have an exploit ability of easy.
This is good news for us.
The technical impacts, however, can be very severe, particularly when it leads to a data breach.
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
well, more like the attacker is sending it right.
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.
Injection flaws are easy to discover when examining code,
but more difficult via testing.
Scanners and fathers can help Attackers find them.
And, I would add, could also help us as programmers to find them a swell.
Now there's a plethora of different types of injection attacks. I'm labeling some here but realize that there are many more.
So we will take a look at command, otherwise known as operating system injection
sequel Injection otherwise known a sequel I
Ex Path Injection. Jason Injection will actually have a demo of Jason Injection
now first sequel injection.
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.
When that sequel statement is received by the Web server,
there is a lack of validation in the application code on the server side.
And so what happens is that sequel is actually received
and executed by our database,
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
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.
Now the first thing to notice
is that there's an or statement following Joe immediately after this or statement
Now the one equals one attack, basically, is any kind of totality of truth,
meaning that so long as the statement equals true,
it can be used in this type of attack.
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
that is being run on the back in.
So sometimes Attackers will
purposefully put in a sequel injection attack, hoping to receive some sort of
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.
So the result of this query when executed where a sequel, vulnerability exists
is that it will divulge full disclosure from the user's table of all the users I. D. S and their passwords.
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,
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.
And so you're going to see in the demo that this will actually divulge all of the contents of the user's table.
Now, command injection is of a similar nature, but this usually occurs due to the immediate execution of arguments received.
This is where we receive something either a targ subzero arcs of one etcetera.
And we just immediately passed that perimeter into our executive command or eggs ical function. The problem is that
maliciously, an attacker could place a command that will allow the attacker
to have escalated privilege on the on the actual machine where
the command is being executed.
Now the case study is on Sony PlayStation.
Sony, of course, was hacked in this instance back in 2011
and the rumor has it that they were actually owned by a version of the one equals one sequel, Injection Attack.
And so you can read more about the history of that at the link below.
Now for the sample code, we're going to take a look at
one of the CERT standards, and
because injection is just so large, it's such a very, very large category.
It's difficult to focus on any one particular type of injection,
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.
So in this example, we have
exclude unsanitized user input from format strings.
Now, without reading to you the fine print of this particular rule
we basically have in the package. In class of Java I au Prince stream to formatting methods format in print, F
now realize that system out and system air our print stream objects that air very commonly used across Java applications.
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.
Inflict validation needs to be added in our code in order to ensure that we are
Onley, receiving acceptable values and not interested data.
So let's take a look at an example.
So if we take a look at our sample code here,
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.
Now let's go ahead and take a look at the code.
So we have this class format and inside, we have
a static instance of the Gregorian calendar. Now what's being simulated in this state is theatrical expiration date,
there's a receiving in of parameters at Argus sub zero,
and whatever is received in is actually being compared to this date.
So in the main method,
it says, the are subzero should contain the credit card expiration date, but it might contain percentage $1 sign.
the day or the year format. Specify IRS,
and if that's the case we run into information leakage.
Now here we have our system out. Remember, that's our prints. Stream class. That's an instance of the prince stream class
and there is thief format method that we were warned about.
Now what it's displaying out is whatever is received in the arts sub zero
And the problem with that
is that the attacker could supply the percent $1 sign tm
for that argument parameter
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.
And although our subzero still may contain some sort of attack or some sort of payload with a format specify WR
because we're no longer allowing the display of arc subzero
it, we basically render that payload attack is being inert.
Okay, so we have the same code here,
but the only thing we've changed is now in that format method of our system out.
We on Lee display percent s,
So whatever gets passed into our subzero
is actually then displayed via the percent s format
instead of being displayed directly as whatever was presented
And so even if our attacker were to supply something
that would cause information leakage, such is this percentage $1 sign month.
The result would just echo back that exact
exact same value instead of leaking the month as it did before.