How I Exploited Unrestricted File Upload by bypassing Regex through Path Traversal ($$$ Bounty) !

Dingus (Amol Verma)
4 min readNov 6, 2023

Its been a while , since my last writeup , but after breaking my thumb like a dumb guy . I am back with another interesting find from my vault of Reports . So without wasting any time , lets jump right into the bug !

So , lets start with , what actually is Unrestricted File Upload ? Its important to know this , because as we go deep , we might need to rethink again ! What actually is Unrestricted File Upload Vulnerability ?

From Official Website of Portswigger —

File upload vulnerabilities are when a web server allows users to upload files to its filesystem without sufficiently validating things like their name, type, contents, or size. Failing to properly enforce restrictions on these could mean that even a basic image upload function can be used to upload arbitrary and potentially dangerous files instead. This could even include server-side script files that enable remote code execution

In simple words , its ability to upload a file type , name , content or size, that is Restricted on the website .

There are many file types , that lead to fatal consequences when opened either at backend side or frontend side and so developers , discard it from being uploaded .

In my case , the target was special , it was not uploading picture on its own server, but instead uploading the picture on s3 and then saving that image link in database , like this —

“headerImage” : “https://cdn.target.com.s3.amazonaws.com/path/to/image.png”

Now , being a curious bird , I tried to put a random image link from Internet and input the link , as that would mean , the website is loading image from a Unknown source and is a direct threat to Content Security Policy !

But I could’nt , as it was protected by this Regex ! This Regex got exposed in error .

/^(?:https?:\/\/)(cdn\.target\.com|s3\.amazonaws\.com\/target-uploads-dev)\/.+(gif|jpg|jpeg|png)/i

Now , lets dive deeper and decode what this Regex means —

  1. First, The image link should start with either https://cdn.target.com.s3.amazonaws.com or https://s3.amazonaws.com/target-uploads-dev
  2. The image link should contain .gif or .png or .jpeg or .jpg in between

Seeing this , I took a deep breath , and started brainstorming as much as I could

Now lets learn some general knowledge about s3 buckets —

The content of s3 bucket can be accessed by going to —

  1. https://bucketName.s3.amazonaws.com
  2. https://s3.amazonaws.com/bucketName

Now with this information I came up with two conclusions —

  1. I can’t bypass Regex with a input starting with https://cdn.target.com.s3.amazonaws.com . Its obvious isn’t ? How can you enter a input starting with this and still load a malicious file from your side
  2. I can perform bypass with https://s3.amazonaws.com/targetBucketName ,however . Let me explain how

I thought to myself , lets try Path traveral here , how you say ? Its easy isnt it ?

If https://s3.amazonaws.com/targetBucketName , holds files of target ,

and

If https://s3.amazonaws.com/AttackerBucket holds file of Attacker

Then what if we input this link —

https://s3.amazonaws.com/targetBucketName/../AttackerBucket

Boom !

The above link resolves to

https://s3.amazonaws.com/AttackerBucket

So , using the same Intuition , I uploaded a svg on my bucket , and constructed this input , to bypass the Regex —

https://s3.amazonaws.com/targetBucketName/../dingusden/xss.jpg.svg

I named the file xss.jpg , to bypass the File extension check in Regex and boom it worked ! You can try opening this file and it will indeed work .

Note : If you want to build a bucket of your own , then always choose us-east-1 region , its the default region . Otherwise endpoint changes and the link to access the bucket becomes like this https://s3.amazonaws.<Bucketregion>.com/AttackerBucker , which would’nt bypass the Regex

Now the only thing needed was the image to be rendered on Client , and it did and I got my $$$ bounty for it 😁

--

--