[Feature Request] Provide a way to prevent authorization tokens from presenting in query string on GraphQL websockets

[neilferreira]

Issue

Our usage of AWS AppSync's WebSockets implementation currently means we’re sending Cognito JWTs using query string parameters to the AWS AppSync GraphQL endpoint.

As per the AWS Documentation, to use AppSync’s GraphQL to connect and initiate a successful handshake with AWS AppSync, a WebSocket client needs the following:

• The AWS AppSync real-time endpoint
• A query string that contains header and payload parameters:
  • header: Contains information relevant to the AWS AppSync endpoint and authorization. This is a base64-encoded string from a stringified JSON object. The JSON object content varies depending on the authorization mode.
  • payload: Base64-encoded string of payload.

With these requirements, a WebSocket client can connect to the URL containing the real-time endpoint with the query string, using graphql-ws as the WebSocket protocol.

This approach is advised against according to some relevant OWASP framework rules and security best practices.

• https://cwe.mitre.org/data/definitions/598.html
• https://portswigger.net/kb/issues/00500700_session-token-in-url
• https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url

Potential Solution

Given that this existing flow is critical to using AWS AppSync, I don’t believe we could change how this initial handshake works by changing how we use the Amplify SDK. From reading into it further, the WebSocket API in JavaScript does not support adding custom headers. The article below states that the general rules of not including credentials in query strings do not apply to WSS.

• https://javascript.info/websocket
• https://faqs.ably.com/is-it-secure-to-send-the-access_token-as-part-of-the-websocket-url-query-params

I would assume that given the general sentiment about it “being ok” to pass credentials in the query string AWS has opted to follow this approach.

According to this article a standard method to overcome this limitation in the WebSockets API is for API maintainers to implement a "ticketing" system.

[coolaqua23]

Any timelines on when will this be implemented? We are also running into same issue with auth token logged in logs as it is part of query param.