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 *

Already have an account? Sign In »

9 hours 31 minutes
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
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.
So, first, let's recall that in the Sands Top 25 overview, we actually have three categories.
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.
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.
So as we look at each ranking,
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
for more details.
That is true for ranking number two as well.
The neutralization of special elements in an operating system command.
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
number 12 C W E. 3 52 is cross that request forgery?
We covered that in Module eight
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.
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.
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.
Such components can include modules, programs, processes, threads or systems.
But what exactly are we talking about in regards to C W E. For 34 unrestricted file upload with dangerous type.
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
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.
Now, as I go through this, I'm gonna explain how just checking for file extension is
not sufficient. And that's because content types can be easily spoofed.
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
that was a file is uploaded. It's not execute herbal.
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
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
in they do it on the server side, and so they think that that's going to suffice
if we just take this example here,
where I'm trying to upload a PHP file, which should be a forbidden extension.
When I captured that request in a proxy to like birth sweet,
I can see that the content type is something else. Something that is not allowed right here says multi part form data
court could say application, octet string or anything like that.
However, I do know based on information on the page, that images are acceptable. Fine,
easy to do. All I have to do is change that content type
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.
Now, if we talk about the possible attacks in this area, they are grave.
The first, of course, is malware. So
malware can actually be embedded in a payload.
You could still be allowing known payloads to be uploaded.
We're gonna talk about in the defense is what we can do.
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.
And this can be done
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
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
and then, of course, web shells or any type of shell commanding control terminals that can be uploaded.
A Web shell, of course, is going to provide that remote terminal to an attacker
through a browser through just a regular http connection. So
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
and what's not being done properly.
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.
But on the back end, on the server side,
there's no
check being done for the file movement.
In other words, the particular directory where the file is being placed to ensure that it's not being moved to a different location,
where the attacker can then execute it,
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.
Now the case study is on shell shock
show shock
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
show that is used for creating commands, creating scripts.
And so the shell shock is quite interesting. Basically, what it allowed was wth e unintentional execution of commands on a server
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
many different vendor implementations of UNIX.
Up Next