Summary
egnyte login uses a default redirect_uri of https://www.egnyte.com, so the OAuth authorization code is returned as a query parameter to the public marketing site. An authorization code is a credential, and delivering it in a URL to that site exposes it to logging and tracking unrelated to the login.
Where the code goes
After approval the browser lands on:
https://www.egnyte.com/?code=<authorization_code>&state=<state>
That URL, including the code, is exposed to:
- Web server and CDN access logs. Query strings are recorded by default in common server and proxy configurations.
- Client-side analytics.
www.egnyte.com loads Google Tag Manager, and a standard page-view tag reports the full page location, including the query string, to the configured analytics endpoints.
- Browser history, and the
Referer header on any third-party request the page makes.
Why this is exploitable, not only untidy
The CLI is a public client. Its client secret ships in the published npm package (DEFAULT_CLIENT_SECRET in src/commands/auth.js), and the authorize request does not use PKCE. The packaged secret is therefore not secret, and nothing else binds the code to the client that requested it. A code recovered from any surface above can be exchanged for a token by anyone who holds it together with the packaged secret. Single use does not close the gap: an abandoned login leaves the code unspent until it expires, and the log and analytics capture happen immediately whether or not the CLI completes the exchange.
To be precise, it is the authorization code in the query string, not the access token; the token is obtained later by a POST to /puboauth/token. The code is still a credential that yields a token.
Suggested remediation, most to least contained
- Add PKCE (
code_challenge on the authorize request, code_verifier on the token exchange). A captured code is then useless without the verifier, even if the current redirect and paste flow are kept. This also removes the need to ship a client secret.
- If PKCE is not adopted, move the redirect off the analytics-instrumented marketing page to a dedicated callback that does not load tag managers and does not log the query string.
- Use a loopback redirect (
http://127.0.0.1:<port>) so the CLI reads the code directly and it never appears in a browser-visited URL. This also removes the manual copy-paste step.
I can open a PR for the PKCE change if that is the direction you prefer.
Related
The generated state value is not verified on return, since the CLI reads only the pasted code. That is minor on its own and would be resolved by a loopback redirect.
Summary
egnyte loginuses a defaultredirect_uriofhttps://www.egnyte.com, so the OAuth authorization code is returned as a query parameter to the public marketing site. An authorization code is a credential, and delivering it in a URL to that site exposes it to logging and tracking unrelated to the login.Where the code goes
After approval the browser lands on:
That URL, including the code, is exposed to:
www.egnyte.comloads Google Tag Manager, and a standard page-view tag reports the full page location, including the query string, to the configured analytics endpoints.Refererheader on any third-party request the page makes.Why this is exploitable, not only untidy
The CLI is a public client. Its client secret ships in the published npm package (
DEFAULT_CLIENT_SECRETinsrc/commands/auth.js), and the authorize request does not use PKCE. The packaged secret is therefore not secret, and nothing else binds the code to the client that requested it. A code recovered from any surface above can be exchanged for a token by anyone who holds it together with the packaged secret. Single use does not close the gap: an abandoned login leaves the code unspent until it expires, and the log and analytics capture happen immediately whether or not the CLI completes the exchange.To be precise, it is the authorization code in the query string, not the access token; the token is obtained later by a POST to
/puboauth/token. The code is still a credential that yields a token.Suggested remediation, most to least contained
code_challengeon the authorize request,code_verifieron the token exchange). A captured code is then useless without the verifier, even if the current redirect and paste flow are kept. This also removes the need to ship a client secret.http://127.0.0.1:<port>) so the CLI reads the code directly and it never appears in a browser-visited URL. This also removes the manual copy-paste step.I can open a PR for the PKCE change if that is the direction you prefer.
Related
The generated
statevalue is not verified on return, since the CLI reads only the pasted code. That is minor on its own and would be resolved by a loopback redirect.