CORS parameters not taken in account on OPTIONS calls to buckets with local names #258

New issue

Open

opened 2022-03-01 10:22:54 +00:00 by lx · 1 comment

lx commented

2022-03-01 10:22:54 +00:00

Owner

OPTIONS calls do not match local bucket names, since these requests are not authenticated.

PR #254 implemented things this way: CORS parameters of a global bucket with the same name will overshadow CORS parameters of the bucket with the local name. If there is no bucket in the global namespace with that name, CORS headers that allow everything are returned, so as to not prevent us from developping web apps that makes use of local bucket aliases. (This only pertains to the OPTIONS call, all other calls to the S3 API are authenticated and proper CORS policies are taken into account even for local bucket names).

Security notice: CORS cannot be relied for as a security measure for bucket with local aliases. Make sure you handle your S3 API keys properly, that's the only true way to secure access to the API.

Please comment here if you have a use case where the behavior of the OPTIONS call implemented in PR #254 is an actual issue.

`OPTIONS` calls do not match local bucket names, since these requests are not authenticated. PR #254 implemented things this way: CORS parameters of a global bucket with the same name will overshadow CORS parameters of the bucket with the local name. If there is no bucket in the global namespace with that name, CORS headers that allow everything are returned, so as to not prevent us from developping web apps that makes use of local bucket aliases. (This only pertains to the `OPTIONS` call, all other calls to the S3 API are authenticated and proper CORS policies are taken into account even for local bucket names). **Security notice:** CORS cannot be relied for as a security measure for bucket with local aliases. Make sure you handle your S3 API keys properly, that's the only true way to secure access to the API. Please comment here if you have a use case where the behavior of the `OPTIONS` call implemented in PR #254 is an actual issue.

lx added the

kind

wrong-behavior

label 2022-03-01 10:22:54 +00:00

RndUsername commented

2023-07-31 11:35:38 +00:00

My CORS rules set via AWS CLI are:

> aws s3api get-bucket-cors --bucket home-dms-bucket
{
    "CORSRules": [
        {
            "AllowedHeaders": [
                "*"
            ],
            "AllowedMethods": [
                "POST"
            ],
            "AllowedOrigins": [
                "*"
            ],
            "MaxAgeSeconds": 3000
        }
    ]
}

And the response I get for the pre-flight OPTIONS is:

HTTP/1.1 200 OK
access-control-allow-origin: *
access-control-allow-methods: POST
access-control-allow-headers: *
access-control-expose-headers: 
content-length: 0
date: Mon, 31 Jul 2023 11:24:58 GMT

But for the POST request which gets called right after that, is:

HTTP/1.1 204 No Content
location: https://localhost:3900/home-dms-bucketclkqs9rq300038jj0ksji37iw
etag: "be91b057ab2b3e393e822ef0453eddc4"
date: Mon, 31 Jul 2023 11:24:58 GMT

Am I missing somthing? I would really appreciate any help.

I'm not sure if this has something to do with it but I get a 'CORS Missing Allow Origin' error on my POST requests but paradoxically not for my OPTIONS requests, so: OPTIONS ✅ POST ❌ 'CORS Missing Allow Origin' My CORS rules set via AWS CLI are: ``` > aws s3api get-bucket-cors --bucket home-dms-bucket { "CORSRules": [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "POST" ], "AllowedOrigins": [ "*" ], "MaxAgeSeconds": 3000 } ] } ``` And the response I get for the pre-flight OPTIONS is: ``` HTTP/1.1 200 OK access-control-allow-origin: * access-control-allow-methods: POST access-control-allow-headers: * access-control-expose-headers: content-length: 0 date: Mon, 31 Jul 2023 11:24:58 GMT ``` But for the POST request which gets called right after that, is: ``` HTTP/1.1 204 No Content location: https://localhost:3900/home-dms-bucketclkqs9rq300038jj0ksji37iw etag: "be91b057ab2b3e393e822ef0453eddc4" date: Mon, 31 Jul 2023 11:24:58 GMT ``` Am I missing somthing? I would really appreciate any help.

RndUsername referenced this issue

2023-08-06 16:37:38 +00:00

Missing Allow Origin Headers #609

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#258

No description provided.