Login bypass: index.html reachable without login about cloudfront-authorization-at-edge

[ottokruse]

GREAT FIND!!

The reason for this is because we've setup a CloudFront custom error response for 403 pointing to index.html. This is needed to enable SPA routing - where the browser requests a URL that does not actually map to an object in S3 but your SPA will make sense of it anyway (in our case / which maps to index.html but this might be anything in your SPA e.g. /orders/123).

Our behaviors don't allow POST requests, so CloudFront will return 403, and since we have the custom error response CloudFront will return that.

So:

• index.html can indeed be fetched by doing a POST against the distribution
• no other document can be fetched, only index.html
• even though index.html is, in case of a SPA, just a tiny file with pointers to other files (that ARE protected) it's still weird that index.html can be gotten to by a POST. This needs to be fixed!

However removing the custom error response for 403 will break SPA routing.

Need to figure out how to do this. Lambda@Edge can solve this (of course) but not yet sure if that's the nicest approach.

I will report back. If you have any thoughts, chime in

[basile-henry]

I saw the 403 redirect trick in the code. To be honest, I am not sure I understand why that is necessary. Once authenticated, isn't it simpler to redirect all non-asset requests to the top level index.html in Lambda?
Maybe I'm missing something, but the 403 and 404 redirects are a bit redundant if Lambda can filter the requests and apply its own rules for redirections.

[ottokruse]

Sure but better to user CloudFront standard functionality than coding stuff yourself in Lambda@Edge right.
Until it bites you of course, like now for the POST. So Lambda@Edge may indeed be the best way forward here.

[ottokruse]

Okay I think I have it sorted out, let me explain.

First, about the reason for the 403 and 404 custom error pages:

• When you request an object that does not exist, S3 returns either 403 or 404 (more on this below)
• We want to map non-existing objects to index.html to enable SPA-routing. This is why we defined the custom error documents for 403 and 404

Now as it turns out, there is an intricacy in S3 that is important to be aware of:

• If your S3 permissions only allow "s3:GetObject" then requesting an object that does not exist results in a 403
• If your your S3 permissions also allow "s3:ListBucket" then requesting an object that does not exist results in a 404

See the discussion here also: https://stackoverflow.com/questions/19037664/how-do-i-have-an-s3-bucket-return-404-instead-of-403-for-a-key-that-does-not-e

So the solution for us is to add "s3:ListBucket" to the bucket policy, thus giving CloudFront that permission. Then S3 will return 404's for non-existent objects, so you would only have to have a custom error document for 404 in CloudFront (mapping to index.html), no longer for 403. Then when you do a POST you'd get the CloudFront standard 403 response, instead of index.html.

However, this is not the whole solution.

When you request the root of your S3 origin, "/", this will actually result in the execution of a ListBucket operation, so now instead of 403 you'll get an XML back with your bucket listing, as we've just added s3:ListBucket to the bucket policy. Luckily, we can fix this easily by setting the "Default Root Object" of the CloudFront distribution to index.html. All problems solved!

I'll update the code now.

[ottokruse]

Fixed in #26