Re:Detailed Financial Histories Exposed for Thousands
by whoisjuan on Saturday December 02, 2017 @07:39PM
(#15835266)
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.
Re:Detailed Financial Histories Exposed for Thousands
by k3a on Tuesday December 05, 2017 @07:27AM
(#15851304)
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?
Re:Detailed Financial Histories Exposed for Thousands
by thesmallestcat on Saturday December 02, 2017 @07:46PM
(#15835289)
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.
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.