关于 SAP Spartacus OAuth 2.0 Resource Owner Password Flow 实现的一些讨论
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:
https://sap.github.io/spartacus-docs/session-management/#configuring-authorization-code-flow-or-implicit-flow
- 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:
{ "error": "invalid_grant", "error_description": "Bad credentials"}
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.
相关文章
- SAP UI5 响应式表格 sap.m.Table 根据不同宽度的屏幕动态决定显示或隐藏 Column 的实现源代码讲解试读版
- 关于 SAP UI5 设备类型检测的实现原理
- SAP UI5 应用开发教程之一百零二 - SAP UI5 应用的打印(Print)功能实现详解试读版
- SAP UI5 应用开发教程之六十七 - 基于 OData V4 的 SAP UI5 List-Detail(列表-明细)布局的实现方式试读版
- 具有SmartFilterBar 的 SAP Fiori Elements 自动触发的搜索操作
- SAP Fiori Elements里Drop down list的实现原理
- SAP Fiori里Contact Support的按钮渲染逻辑
- SAP成都研究院非典型程序猿,菜园子小哥:当我用UI5诊断工具时我用些什么
- how does SAP ui5 know the phone, tablet type, os type
- SAP CRM 创建销售订单时报错 - CRM_ORDER_MISC 020
- 关于SAP ABAP调试器的实现源代码,RSTPDAMAIN报表
- SAP订单上Shipping抬头和行项目字段的持久化实现原理
- SAP Fiori Elements edit按钮的ABAP端实现细节
- 使用cds view annotation实现SAP UI5的drop down list效果
- SAP Commerce Cloud 里 OAuth2 Client 的两种配置方法
- SAP Spartacus 服务器端渲染单步调试步骤之二:在服务器端执行应用程序 Angular 代码
- SAP Spartacus 用户认证的实现
- 关于SAP Spartacus tab按键Accessibility技术实现的一些问题和波兰同事的解答
- SAP CRM Pricing Procedure中的Doc和Customer Procedure在哪里维护
- SAP CRM WebClient UI Social post高级搜索的Selenium实现
- SAP成都研究院李三郎:SCP Application Router简介
- 关于将本地 SAP UI5 应用配置到本地 Fiori Launchpad 的技术实现深入讲解试读版