Hacker News new | past | comments | ask | show | jobs | submit login

Insecure defaults are a footgun.



They're secure by default on S3. You have to go out of your way to make it public, or grant anyone else access.


It's not that so much but that novice users see two ACLs: "Public" and "API Key I use to deploy." So it's very easy to "fix" an access issue by making a bucket public, with the alternative being to give your application the keys to the kingdom. This combined with S3's most frequent use as a file server means that buckets get opened up. You have to jump through hoops and dig into Amazon's access model for anything more nuanced, and only people experienced with AWS will understand or know how to do that.

Making a bucket public should come with red flags, and there should be a simpler way for client-side code to securely access a bucket. If I save a user's uploaded files to the filesystem, I usually have to go out of my way to expose that. Even novices are less likely to put them inside the web root, so exposing such files involves jumping through hoops. Opening a bucket to the world is too easy in AWS.

Calling this situation "insecure defaults" was imprecise of me, my point was more that Amazon gives you a Big Red Button to "fix" things which has consequences like this.


It does have red-flags. When you try to set a bucket to "public" in S3 it literally tells you: "This bucket will have public access. Everyone will have access to one or all of the following: list objects, write objects, read and write permissions."

I mean, there's a difference between being a novice and being stupid.


They were times when people used to manage their servers and they had to be careful on how to use 'rm -rf' or 'dd' tools.

I find it funny how today there have to be red flags, warning signs and double confirmations everywhere. Are people less competent or are there simply lower requirements when hiring them?


Not if you use aws-cli. But I think the larger issue is that Amazon doesn't provide a low-friction, secure way for applications to access their buckets. A good way would be for each bucket to come with its own access key, or expiring tokens that you could query on the backend and use from the browser. Just spitballing of course.


Absolutely.

Windows tells you that using a password is probably a good idea for a user account. Many websites these days force you to use a combination of letters/numbers/special characters.

Why doesn't Amazon say "hey, this is publicly available, you wanna fix it?"


> Why doesn't Amazon say "hey, this is publicly available, you wanna fix it?"

They do. It's clearly warned about in the interface both at the time you make it so and with a big "PUBLIC" sticker label afterwards. What's more, I've received warning emails from AWS notifying of (intentionally) public buckets.

Public buckets for private data are a deliberate and wilful choice by lazy, reckless administrators.


I noticed this when I went into my console the other day. (Ironically, to set up a public bucket for something.) I don't think the UI was bad before but, now, you'd have to be pretty clueless to have a bucket public by accident.


You've always had to make it public deliberately. The new console UI makes setting a bucket to public a very deliberate effort.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: