LCNC-SEC-02: Authorization Misuse
Risk Rating *
Connections are first-class objects in most no-code/low-code platforms. This means connections between applications, other users, or entire organizations. Applications can also be shared with users who should not have access to their underlying data. In addition, the application may have a broad authorization scope more than the use case demands.
No-code/low-code applications aren’t built in silos. Their impact is based on integrations across the organization’s stack through on-premise, SaaS, PaaS, and cloud platforms. Most no-code/low-code platforms come built-in with a large set of connectors, i.e., wrappers around APIs, which allow quick and easy connectivity. Connectors and user credentials form connections, which are first-class objects in most no-code/low-code platforms. This means that connections can be shared among applications, with other users, or with entire organizations.
Many no-code/low-code platforms abuse OAuth authorization flows by querying and storing user refresh tokens and re-using them at will to increase productivity and reduce time-to-deliver. This allows business users to quickly set up connections without thinking about secrets or permissions; at the same time, connections are embedded with user identities that are difficult to monitor or revoke. Even though OAuth refresh tokens are designed to be short-lived, they are most frequently valid for a few months or even years. Hence, a connection created by a business user in under a minute could persist in the no-code/low-code platform for an extended period and often get used by other users for different purposes than the original intention.
An authorization scope controls the access to resources and assets of an organization. No-code/low-code platform application developers prefer broad authorization scope for their applications to make them as generic as possible. For organizations, this allows quick and easy setup of applications, which they can later use for other use cases without needing another application. The broad authorization scope does come at the cost of unnecessary risk of authorization misuse.
Example Attack Scenarios
A developer creates a connection to their corporate email account. They inadvertently click the “share with everyone” option, granting either usage permissions or full ownership. Every user in the organization, including contractors and vendors, gains access to their corporate email account. A malicious user triggers a “forgot password” flow and uses the connection to follow through with the process and gain control over the account.
A developer creates a simple application to view records from a database. The application is configured to ensure each user can only view related records. However, the application is configured in such a way that the underlying database connection is implicitly shared with its user. An application user can use the database connection directly, gaining full access to all records.
Admin connects an application to their source code management system (e.g., Bitbucket) using a service or application account. The provisioned service or application account has unrestricted access to all repositories to enable seamless integration. Any internal user can abuse this connection to access restricted repositories they usually don’t have access to.
A developer creates a simple application to submit forms from one platform to another. The application, however, is configured to require authorization to edit and delete form submissions when just creating form submissions should have been enough.
How to Prevent
- Disable or monitor the use of implicitly shared connections.
- Adhere to the principle of least privilege when providing access to environments that can contain shared connections.
- Monitor no-code/low-code platforms for over-shared connections.
- Educate business users on the risks of connection sharing and its relation to credential sharing.
- Explicitly refresh OAuth tokens on a regular basis by re-authenticating connections.
- Carefully review the scope an application requires and adhere to the principle of least privilege.