Ghostery crashes direct Amazon S3 uploads

[rbjarnason]

Description

Here is a ticket I opened on Amazon until I realized to turn off the Ghostery plugin that then fixed this problem.

Suddenly today direct accelerated uploads are not working in my development buckets nor on the 3 production cluster buckets.

This was working yesterday on the same Chrome 73 version but suddenly stopped working everywhere on Chrome. This still works on Firefox.

Any ideas?

On my dev box:
Access to XMLHttpRequest at 'https://yrpri-video-development.s3-accelerate.amazonaws.com/sdkrj90_video123.mp4?AWSAccessKeyId=AKIAJVGFSTIVBKEINF7A&Content-Type=video%2Fmp4&Expires=1553014686&Signature=1MNi%2BZVGhWWzZ9kFMlylf7xVz%2BU%3D&x-amz-acl=bucket-owner-full-control ' from origin 'http://localhost:4242 ' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.

On one of our production clusters:
Access to XMLHttpRequest at 'https://is-production-video-uploads.s3-accelerate.amazonaws.com/pmqb10q_video192.mp4?AWSAccessKeyId=AKIAIZ72LATOUSTFIJIQ&Content-Type=video%2Fmp4&Expires=1553014944&Signature=tVhe2rBl7aOg1HdA%2F6VTD%2Fg1vhc%3D&x-amz-acl=bucket-owner-full-control ' from origin 'https://app.idea-synergy.com ' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.

Req headers:
Provisional headers are shown
Access-Control-Request-Headers: content-type
Access-Control-Request-Method: PUT
Origin: https://app.idea-synergy.com
Referer: https://app.idea-synergy.com/group/179/open
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36

Response headers:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://app.idea-synergy.com
Location: https://is-production-video-uploads.s3-accelerate.amazonaws.com/9w3n8fv_video193.mp4?AWSAccessKeyId=AKIAIZ72LATOUSTFIJIQ&Content-Type=video%2Fmp4&Expires=1553015001&Signature=qd7Fb33AKxgNFssQUnGS7NUtcaU%3D&x-amz-acl=ghostery
Non-Authoritative-Reason: WebRequest API

General request info from Chrome dev tools:
Request URL: https://is-production-video-uploads.s3-accelerate.amazonaws.com/9w3n8fv_video193.mp4?AWSAccessKeyId=AKIAIZ72LATOUSTFIJIQ&Content-Type=video%2Fmp4&Expires=1553015001&Signature=qd7Fb33AKxgNFssQUnGS7NUtcaU%3D&x-amz-acl=bucket-owner-full-control
Request Method: OPTIONS
Status Code: 307 Internal Redirect
Referrer Policy: no-referrer-when-downgrade

x-amz-acl: bucket-owner-full-control

Expected Behavior

Direct uploads to Amazon does not crash my app with an error.

[What you expected to happen]

Actual Behavior

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Versions

• Browser: Chrome
• OS: Ubuntu
• Node:
• NPM:

[christophertino]

I think we had a similar issue recently that @sammacbeth fixed. I see in one of the headers x-amz-acl=ghostery which usually means anti-tracking doesn't like that parameter.

[rbjarnason]

I reported a similar issue last year and it was fixed, this is something new from today as uploads were working yesterday. #263

[christophertino]

Ah yes I remember. We'll take a look and see what's happening.

[rbjarnason]

If you have not recently released a new version that might have broken this then last time there was a 403 error but this time it has to do with "307 Internal Redirect" - maybe this is a non-common situation @ Amazon in this context that exposes a problem with Ghostery. Just speculating...

[mrfrase3]

Hello,

This just happened to me as a deployment finished running and gave me a heart attack, oddly timed update? 🤔

In my case, it is blocking s3 direct download with a pre-signed cert link. As mentioned by @rbjarnason there are a few 307 redirects, ghostery modifies the query header, and then AWS throws a fit for not having a valid request.

It seems to be modifying the X-Amz-Credential query from AKIAJWEEHRTK77CJDOSA/20190425/ap-southeast-2/s3/aws4_request to ghostery.

AWS S3 response:

<Error>
  <Code>
    AuthorizationQueryParametersError
  </Code>
  <Message>
    Error parsing the X-Amz-Credential parameter; the Credential is mal-formed; expecting "<YOUR-AKID>/YYYYMMDD/REGION/SERVICE/aws4_request".
  </Message>
  <RequestId>
    630CA428FE54E74A
  </RequestId>
  <HostId>
    wJ7GwD+RCMvaxWxpzLKWyy5/PjzZPsLS8+rW8ksuiR6ICsWWQmWdDeq0ZELLfcD/PSAAt7QtlWo=
  </HostId>
</Error>

307 Redirects:

Query Headers Before:

Query Headers After:

chrome 73, ghostery 8.3.3

[sammacbeth]

It looks like this is triggered by developer conditions, because the same credentials are used across multiple origins (staging and production), and the volume is users with this value is low (dev-credentials in use). These two factors will trigger the parameter replacement mechanism.

If the credentials are only used on a single origin in production, then this should not cause an issue for your users. However, this is a common use-case we'd like to fix, so I'm pushing some whitelisting rules for these AWS endpoints to try to prevent this issue in the future.