McAfee discovered that it is possible to retrieve a valid authentication token for a user, using an unauthenticated request to the application’s backend API.
通过没有认证的请求，调用后台API，获取某个用户的Authentication token.
The application uses OpenID Connect OAuth 2.0 to authenticate users.
The OAuth 2.0 framework supports different flows that can be implemented by an application to retrieve user access tokens.
During testing, McAfee observed that the application appears to implement the Authorization Code Flow directly from the client application, using client-side JavaScript code to generate the POST request to retrieve the access token, which includes a client_id and client_secret parameter in the request. This is not appropriate for a single-page application (SPA) such as this, as it exposes the client_id and client_secret information to the client, either via embedded JavaScript source, or using an interception proxy.
client_id=mobile_android&client_secret=secret&grant_type=password&username=ct******@gmail.com&password=
Authentication Flow
Spartacus 2.1 uses what is called “Resource Owner Password Flow” or “Code Flow” as it’s called in the issue description.
“Resource Owner Password Flow” is the only flow fully supported by the SAP Commerce backend.
Spartacus 2.1 has built-in support for only this flow. Spartacus 3.0+ can be configured to work with alternate flows, but again, the alternate flows are not fully supported by the SAP Commerce backend.
As a reference, here is the spartacus 3.0 documentation that provides more info about this:
Spartacus exposes the “client_id” and “secret”.
Some backend endpoints like “customer registration” and “forgot your password” require a “client” authentication before they can be called.
This “client” authentication is performed by authenticating with a grant type of “client_credentials”. The access token provided for a “client_credentials” authentication is not associated with a specific user and only allows an occ client to call a handful of endpoints that don’t otherwise require a user authentication.
Someone could discover the “client” credentials (“client_id” and “secret”) using the browser dev tools, but these credentials can only be used to get a “client” access token and call endpoints that already do not require any user authentication.
This backend api behaves like this by design and Spartacus needs to comply with this contract.
The authentication endpoint allows account enumeration.
I tried to reproduce the issue from the information provided and I could not.Using the “grant type” of “password” in the authentication request gave the following response whenever the correct password was not provided:
There was no difference between an attempt with a username that exists and attempts with a username that does not exist in the system.
Therefore I can not see an account enumeration vulnerability with the observed behaviour.
Using a “grant type” of “client_credentials”, the user in the request is ignored and a “client” token is returned with no access to customer restricted endpoints.
You can perhaps double check the “grant type” used in the authentication requests or provide us with updated repro steps.
Auth requests can obtain an access token for a user without knowing his password
I tried to reproduce the issue from the information provided and I could not. I observed the expected behaviour.
If you post an authentication request with a “grant_type” of “client_credentials”, the access token will be generated for a “client” authentication based on “client_id” and “secret” regardless if a username is also provided in the post request.
The “client” authentication token will not work with user restricted endpoints.
If you post an authentication request with a “grant_type” of “password”, the backend will only authenticate a given user when the correct password is provided.
I was not able to get an access token for an existing user without providing his password.
Perhaps try the use case again and double check which “grant_type” is provided or provide us with updated repro steps.
Spartacus uses a new user session if a valid token is pasted in local storage.
While this is not a supported use case, this is not a security flaw. To get a user access token, a valid username/password pair needs to be provided to the auth endpoint.
