Expensive Lessons Learned Running A Free File Hosting Web Service

Last updated: February 22, 2018

Towards the early part of 2017, I embarked on creating a bunch of quick single-purpose web applications to keep myself busy and sharp. One of those apps was a temporary file storage web application called Tempfile.cloud.

The premise was simple: you get 1gb of free upload space and your files have an expiry of 24 hours.

I threw some advertisements on there and then shared it around. Surprisingly, it got some traffic. Turns out file sharing sites not covered in malware-laced banner ads/widgets, require you to signup and have no Russian tracking scripts resonate.

I did the numbers and the cost of storing even a few hundred gigabytes of files was going to be cheap on Amazon S3, both the bandwidth and storage costs. Using an S3 bucket policy, I was able to automate the deletion of files after 24 hours.

The site didn’t really generate any income for me and it got a few thousand visitors per month, people were using it. Costs for the first few months were not even $1 and the ads (whilst not very profitable) were covering the costs (and then some).

Then one month it all changed… I got my monthly Amazon bill and almost had a heart attack. My beloved sub $1 application just netted me a bill for almost $500 for just one month.

I immediately went to Amazon thinking it was some kind of mistake that my bill had jumped so much.

Once I realised it wasn’t, I then started digging. Did I all of a sudden start to get more users because people loved the product, was my site being used as a new Pirate Bay replacement or the next Wikileaks? I had to know.

The traffic stats were not showing a spike in new users, I didn’t make it to the front of Reddit, Product Hunt or Hacker News. Turns out a few standard definition movies had been uploaded, that’s just where it starts.

Digging even deeper, I realised that not only were movies being uploaded, but my site had inadvertently become a movie streaming platform and a couple of videos shared on a forum. Thankfully these were not dodgy movies (I log IP’s anyway).

It turns out I had failed to enforce uploaded files are to be downloaded by the user. This meant I had created a site where you could upload any type of file and then hotlink it (for 24 hours). Movies and music, anything you can stream. I had just created a Netflix for piraters, without the discovery UI.

The lesson here is, if you’re going to allow files to be uploaded and you’re not restricting the type (like me), make sure you enforce a policy which always forces the files to be downloaded. Otherwise, you could be drowned in a sea of expensive bandwidth fees.

The story didn’t end badly for me though. Kudos to Amazon, when I reached out to them they wiped the entire bill and understood that it was a mistake (even if it was my fault). They didn’t have to do that, but I am grateful that they did.

As for the site. It is still up here – however, file uploads are disabled. I am planning on re-enabling them shortly once I sit down and make sure this kind of thing doesn’t happen again.

 

Dwayne

 

3 thoughts on “Expensive Lessons Learned Running A Free File Hosting Web Service

  1. Interesting read. Thanks for sharing this Dwayne – a good reminder for the rest of us. Great ad for AWS too.

  2. Hi Dwayne you say “make sure you enforce a policy which always forces the files to be downloaded”.

    Did you mean to say “by the original uploader”? How can you enforce that unless you issue credentials (which could still be shared) or you limit based on IP address (which could be problematic as a DSL service reconnecting could change IP).

    Or did you mean to say “always forces the file to be downloaded” as opposed to streamed? Can the web tier tell the difference in this case?

    $500 is about 50TB of downloads, so it’s easy to see how it can spiral out of control.

  3. @Kevin Frey

    What I mean is just ensuring that your files you have in your S3 bucket cannot be used directly. You can do this by setting the `Content-Disposition` header to `attachment` when you upload the file. So whenever the file is requested, the user is prompted to download and save it to their machine.

    What happened in my situation was I didn’t force the uploaded files to be downloaded, so if you uploaded a video file for example and visited the URL, your browser would then play it inline.

    I will never know what happened in my situation, whether someone intentionally exploited this or not. But, the reason this spiralled out of control is that I wasn’t monitoring my AWS usage or had any alerts. I naively assumed my usage would stay around that $1 range. So, this went on over the course of a month.

    I am pretty fortunate that it didn’t go beyond that figure and get a bill for thousands.

Leave a Reply

Your email address will not be published. Required fields are marked *