Web Shell Upload via Content-Type Restriction Bypass

Web Shell Upload via Content-Type Restriction Bypass - 双语字幕

In this video, we're going to take a look at one of the file upload vulnerability labs on Port Sugo's Web Security Academy.

The lab is called,

web shell upload via content type,

restriction bypass, and we'll start off by having a quick recap of file uploaded vulnerabilities before we dive into the practical lab.

I'm over in the learning material section now on the web security academy in the file uploaded vulnerabilities section,

and I'll try not to spend too much time here because we have done some videos already on file uploaded vulnerabilities,

so the video with the first lab will have covered some of this theory already.

So what are file upload vulnerabilities?

They occur when a web server allows users to upload files without sufficiently validating things like the name, the the contents, or the size.

Failants properly enforce restrictions could mean that a basic image upload function could be used to upload arbitrary and potentially dangerous files instead.

This even include server-side script files that allow remote codec security.

In some cases,

the active upload in the file itself is enough to cause damage,

other attacks may involve a follow-up HTTP request for the file to trigger the execution by

the So there are generally two key factors to consider when assessing the impact of file upload vulnerabilities.

The first is the aspect of the file that the website fails to validate, so is it the size, the type, or the contents?

And the second are the restrictions that are imposed on the file once it's been uploaded.

So our worst case scenario is the file type not being validated properly.

This might mean that we can upload some malicious code,

so for example, if you have an image upload on a website, perhaps you can upload an avatar or something.

You could have uploaded an image,

but it doesn't actually make sure that the file you're uploading ends with.jpg or .png,

and instead you're able to upload a PHP file,

and if the server is able to execute PHP,

then whenever you try to view the avatar,

rather than print it to the screen as an image, it will execute the code that's in the file.

So this could allow the attacker to gain control of it.

The second example is the file name.

So if this isn't validated properly, you could potentially use a directory traversal vulnerability.

So we could potentially set the name as like dot dot slash dot dot slash dot slash etc password.

And then whenever you try to view that file,

let's say again,

it's an avatar,

it's going to go and look at dot dot slash dot slash dot slash etc password for the file and hopefully print that to the screen.

And then the final example is the file size.

So by failing to limit the file size,

attackers could potentially upload very large files to the system,

which might crash the server just in trying to do the transfer, or might fill up the available disk space.

So these file upload vulnerabilities arise when validation is inherently flawed or easily bypassable.

For example, developers might use blacklists to prohibit dangerous file types.

So they say you cannot upload a .php file extension to the web server.

But the problem is there are so many different file types that it's hard to find them all.

Generally, it's better to use an allow list and say rather than prohibit in specific file extension, to say which file extensions are safe.

So example, you're only allowed to upload .png or .jpg.

And to give you an example of that, let me just open up the PHP file extensions list.

So here's an example of a list from payloads, all the things.

So even if you say that dot PHP isn't allowed, you would also need to account for these other extensions as well.

And it's just a lot safer to say will only allow dot PNG or dot JPEG or whatever file type you're in.

expected.

Another example of an inherently flawed approach is reliant on client-side validation as a security measure.

So if you have a client-side script which is just making sure that the file a user uploads is a .png file,

all an attacker has to do is upload a .png file, intercept a request in burp, and then change that to .php.

They could also just simply disable the client-side validation or make some changes to the JavaScript.

Unfortunately, even if you do have strong validation measures, so you've got a good allow list and you are validating everything on the

may be discrepancies across interconnected systems which can lead to file upload vulnerabilities.

So, how do web servers handle requests for static files?

If the file type is non-executable, it'll generally just send the contents of the file as the HTTP response.

If it's executable, for example, a PHP file and the servers configured to execute that file, it should execute the script, basically.

But if it is executable and the servers not configured to execute files of this type,

or is not able to, for example, a PHP file on a JSP server or vice versa, then it'll generally respond with an error.

or with text.

So it responds with the source code of the file, then you could potentially use that to leak code and other sensitive information.

We're going to skip the next section because this was the first challenge that we uploaded on file upload vulnerabilities,

which is just exploiting an unrestricted file upload to deploy a web shell.

So you can go back and check that video if you want her more.

What we are interested in is the exploiting a flawed validation of file uploads,

and specifically the flawed file type validation which is related to the lab that we're going to be looking at today.

So this section starts by telling us how the browser deals with submitting HTML forms,

so it will send the data in a post request with a content type of form URL.

And that's fine for simple data,

but for sending large files, so large amounts of binary data, the preferred approach is to use this multi-part form data.

So consider a form containing fields for uploading image, providing a description and entering the username.

It might look something like this.

And we've got an example of a post request then.

So this is going through to the images endpoint on normal website.

And we can see we have this form data.

And the first part of it is the name, which is image, and the file name.

And then we actually have the content of that image with the content typeset as well.

And then the second part of that form is the description of the image.

So then we've got the text for that.

And also the username as well, where we've got the username.

So the message separate parts,

and each part has this content disposition header,

and can also have its own content type header as well, which a server the MIME type of the data.

So one way that websites may validate the file uploads is by checking this content type header and making sure it's the expected MIME type.

So if the service expects an image files, it might only allow image slash JPEG or image slash PNG.

But problems arise when the value of this header is implicitly trusted by the server and no further validation is performed

to check whether the contents of the file or the file extension actually match the supposed MIME type.

So this can easily be bypassed using tools like Okay,

so with that out of the way, let's take a at this practical lab, which web shell upload via content type restriction bypass.

And it tells us that there's a vulnerable image upload function which attempts to prevent users from uploading unexpected file types,

but relies on checking user controllable input to verify this.

To solve the lab, we need to upload a basic PHP web shell.

and use it to exfiltrate the contents of the secret file in the Carlos directory.

Submit this using the button provided in the banner.

So we've got a username and a password, Wiener and Peter, so we'll go and log in with those first of all.

Okay, so we'll go to my account and we'll log in.

Oh, we'll try.

there we go login we can update our email we can upload an avatar so let's go and

do the second one since this is the file upload vulnerability I'm gonna upload a

web shell here just have this default PHP web shell which let me just actually

go and print that out shell.php

very simple web shells with literally just the PHP script which is going to

call system and then it's going to use the get parameter CMD as the input to system.

So if we provide CMD equals LS this is going to replace this bit with LS and then call system LS which is going to do exactly that.

So let's try it let's And we get this message saying sorry the file type is not allowed only image JPEG and image PNG are allowed

Okay, cool.

Let's take this to the burp suite intruder not intruder repeater So I'm going right-click the request that we just sent off and I'm going to send that to

repeater or control and R.

We go through here and we've got this form just like we saw in that example and notice at the moment the content type is set to application x-php which is not one

of these allowed content types.

So we'll change this to image slash jpeg and hit send.

I notice it says it's been uploaded,

so I'm going to go back to the account and I'm going to right click it and say open a new tab.

And it's got this dot PHP extension,

which is always good to see from an attacker's point of view, not so good from a defender's point of view.

And we're going to set the get parameter to command equals, and then let's say LS.

There we go, it's showing shell dot PHP.

We could also take this through to the repeater if we just want to get a nicer interface to work with.

So we can send that there.

We get shell dot PHP, which is awesome.

So we can do now cats.

And I'll do a plus to make sure that you are encoded, and then it was home, call us.

send.

There we go, we get the secret, we go back to submit the solution and we've solved the lab.

up.

So looking at our file upload vulnerability here, really, there's a few things that should have been done.

First of all, the file name is ending with dot PHP.

So there should have been some validation in place to make sure that the file extension here matches an image file extension.

So if this is image slash JPEG, why doesn't this end with dot JPEG?

Another thing that could have been done is checking the actual content type of the file.

So although the content type header is specified here,

you could have something which is checking for the magic bytes,

so the signature of the file, the header of the signature should and should start and end with specific values.

depending on the type of image it is,

you can also do other things like checking exif data as well,

although all of those do have bypasses, but each of these checks will add another layer of security.

The other thing which is important is not telling users whether file has been uploaded to.

So even if this was vulnerable as it is now where we cannot load a malicious shell,

if we don't know where that shell is located,

for example,

if it's in a directory that we don't have access to,

or if the file name has been randomized, something like that, maybe the MD5 hash.

Which is using a salt so we don't actually know what the file name is in that case

There's no way for us to directly access the file and make the server execute up anyway

That's gonna wrap it up for this challenge challenge,

I'm going to recommend that you check out the Integrity Academy where we have done some documentation on some of these vulnerabilities and also links the videos for

the Portsmouth River Web Security Academy.

So we've already got three file upload vulnerability videos.

This will be the fourth.

I'll try and get this category wrapped up and then we'll move on to another one.

I'm thinking maybe JWTs.

But if you have any specific recommendations,

if there's any web security academy labs that you'd really like to see solved, or if there's any of the video types.

let us know and I hope you've enjoyed this video.

If have any questions or comments, leave them down below.

Thanks.

翻译语言

选择翻译语言

视频总结导出字幕口语评测

解锁更多功能

安装 Trancy 扩展，可以解锁更多功能，包括AI字幕、AI单词释义、AI语法分析、AI口语等

兼容主流视频平台

Trancy 不仅提供对 YouTube, Netflix, Udemy, Disney+, TED, edX, Kehan, Coursera 等平台的双语字幕支持，还能实现对普通网页的 AI 划词/划句翻译、全文沉浸翻译等功能，真正的语言学习全能助手。

支持全平台浏览器

Trancy 支持全平台使用，包括iOS Safari浏览器扩展

多种观影模式

支持剧场、阅读、混合等多种观影模式，全方位双语体验

多种练习模式

支持句子精听、口语测评、选择填空、默写等多种练习方式

AI 视频总结

使用 OpenAI 对视频总结，快速视频概要，掌握关键内容

AI 字幕

只需3-5分钟，即可生成 YouTube AI 字幕，精准且快速

AI 单词释义

轻点字幕中的单词，即可查询释义，并有AI释义赋能

AI 语法分析

对句子进行语法分析，快速理解句子含义，掌握难点语法

更多网页功能

Trancy 支持视频双语字幕同时，还可提供网页的单词翻译和全文翻译功能