Part 2 Explanations
Video Activity
This lesson focuses on the unrestricted upload of file with dangerous type. This means components exchange information and/or data via insecure means. When an unrestricted upload of file with dangerous type occurs, it is because of a result of coding which allows an attacker to upload or transfer harmful files (e.g. extensions and payloads). Partic...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson focuses on the unrestricted upload of file with dangerous type. This means components exchange information and/or data via insecure means. When an unrestricted upload of file with dangerous type occurs, it is because of a result of coding which allows an attacker to upload or transfer harmful files (e.g. extensions and payloads). Participants also learn about possible attacks via malware, denial of service and web shell code. Finally, participants learn some HTML sample code.
Video Transcription
00:04
Hello and welcome to the side. Very secure coding. Course my name miss anywhere, and this is sans top 25 category. Insecure interaction between components.
00:16
So, first, let's recall that in the Sands Top 25 overview, we actually have three categories.
00:25
The three categories include insecure interaction between components, risky resource management and porous defenses. This module we are focusing on the first insecure interaction between components.
00:39
The bottom of the slide shows theory. Rankings included in this category and that is 1 to 49 12 and 22. Let's take a look at each.
00:53
So as we look at each ranking,
00:55
we can see that we have covered many of these areas already. If we look a rank Juan C W E 89 improper neutralization of Special elements Houston sequel command that was actually covered in module one a one injection. So please refer back to that module
01:15
for more details.
01:15
That is true for ranking number two as well.
01:19
The neutralization of special elements in an operating system command.
01:26
Now, when we go to ranking four c w e 79 proper neutralization of input during webpage generation, this is our cross site scripting. And of course, we covered that in Module three. That's a three cross site scripting
01:42
number 12 C W E. 3 52 is cross that request forgery?
01:47
We covered that in Module eight
01:49
and then 22 c W E 601 is Are you r l Redirection to untrusted site. This was our unveil. It dated redirects and forward section module 10.
02:04
So what that leaves us with is just one ranking in this category, and that is nine C W E 4 34 unrestricted upload of file with dangerous type.
02:16
So let's go ahead and have a definition in regards to this particular category. The insecure interaction between components category identifies weaknesses related to insecure methods or means in which components exchange information or data.
02:37
Such components can include modules, programs, processes, threads or systems.
02:43
But what exactly are we talking about in regards to C W E. For 34 unrestricted file upload with dangerous type.
02:53
This is specifically telling you that your code may allow Attackers to upload or transfer dangerous file types. And what does that mean? It means
03:07
file types that generally are executed ble because they have particular content types or they have particular payloads that contain shell code inside of this payloads.
03:23
Now, as I go through this, I'm gonna explain how just checking for file extension is
03:30
not sufficient. And that's because content types can be easily spoofed.
03:37
Also, we are going to take a look at how permission settings really mean a lot in regards to file uploads. And you'll see this in the demo. A swell. You will want to ensure
03:52
that was a file is uploaded. It's not execute herbal.
03:55
And then, of course, a lot of this revolves around the lack of validation or even the incorporation of malware scanning that's not being done on the server side
04:06
now. First, I want to just explain a little bit further why extension checks are ineffective because this is commonly done. A lot of programmers will just look for a certain extension
04:19
in they do it on the server side, and so they think that that's going to suffice
04:28
if we just take this example here,
04:30
where I'm trying to upload a PHP file, which should be a forbidden extension.
04:39
When I captured that request in a proxy to like birth sweet,
04:45
I can see that the content type is something else. Something that is not allowed right here says multi part form data
04:54
court could say application, octet string or anything like that.
04:59
However, I do know based on information on the page, that images are acceptable. Fine,
05:05
easy to do. All I have to do is change that content type
05:11
to be one of the acceptable types. And here you can see, I've changed it to image J. Peg and then my file happily gets uploaded.
05:20
Now, if we talk about the possible attacks in this area, they are grave.
05:26
The first, of course, is malware. So
05:29
malware can actually be embedded in a payload.
05:32
You could still be allowing known payloads to be uploaded.
05:40
We're gonna talk about in the defense is what we can do.
05:43
Denial of service is another possibility. So you should always have limits as faras. How big the file size ca NBI. You should never allow zip files because zip files actually can contain large, large size files.
06:02
And this can be done
06:03
in a in a very sneaky and crafty way, such as the zip bomb, which basically is like a Russian doll where you've got
06:13
one zip zip file contained within another contained within another. And when it is extracted on the server side, it can be large gigabytes of data
06:26
and then, of course, web shells or any type of shell commanding control terminals that can be uploaded.
06:34
A Web shell, of course, is going to provide that remote terminal to an attacker
06:43
through a browser through just a regular http connection. So
06:47
these are definitely severe possible attacks. Now, if we take a look at our sample code, I really don't have sample code to show you that's necessarily bad. All I can do is show you a sample code of a form that receives a file
07:05
and what's not being done properly.
07:09
So in this particular HTML, of course, you can see that we have a form that's going to receive an input type of file.
07:19
But on the back end, on the server side,
07:23
there's no
07:25
check being done for the file movement.
07:29
In other words, the particular directory where the file is being placed to ensure that it's not being moved to a different location,
07:38
where the attacker can then execute it,
07:41
and that the execution permissions on that file after it's uploaded are basically made inert, so you want to make sure that there's no execution privileges to that file on the Web server.
07:56
Now the case study is on shell shock
08:00
show shock
08:01
has to do with Bash Shell, and if you're not familiar with what that is, every single UNIX or Lennox operating system has some sort of
08:11
show that is used for creating commands, creating scripts.
08:16
And so the shell shock is quite interesting. Basically, what it allowed was wth e unintentional execution of commands on a server
08:26
when those injected commands working caffeinated to the end of function definitions. And usually those definitions are already available in environment variables on the server. And so this became a real problem because Bash L is ubiquitous. It's used
08:46
for
08:46
many different vendor implementations of UNIX.
Up Next
Instructed By
Similar Content
