Misconfigurations can cause many Microsoft Power Pages sites to expose sensitive data

Many websites built with Microsoft Power Pages expose sensitive information from their databases due to a poor understanding of access control configurations and default settings, according to a report from researchers at SaaS security provider AppOmni.

Insecure custom code implementations and overprovisioned access to databases contribute to the issue, the report’s authors said.

These misconfigurations typically lead to the exposure of personally identifiable information (PII) from customer records and sensitive internal organization files that are stored in these business websites, said Aaron Costello, AppOmni’s chief of SaaS security research.

Costello noted that during his research, which involved authorized testing of websites, he uncovered several million sensitive records. Extrapolating that to all websites based on Power Pages, the score is probably much bigger.

“In one case, a large shared business service provider for the NHS was leaking the information of over 1.1 million NHS employees, with large portions of the data including email addresses, telephone numbers, and even home addresses of the employees,” Costello said in his report. “This particular finding was responsibly disclosed and has since been resolved.”

Misunderstanding Power Pages access controls

Microsoft Power Pages is a low-code software as a service (SaaS) platform that enterprises can use to create business websites. Compared to building websites from scratch, Power Pages already provides a role-based access control (RBAC) implementation, a built-in database in the form of Microsoft Dataverse, and drag-and-drop interfaces for various components that can be used to build a website.

The front end of the website communicates with the database using three possible APIs with the Web API being the newest and most modern addition and the one that provides the full range of permissions on records. The older OData Feed and Embedded List APIs only provide read operations.

Power Pages provides multiple roles and different permissions that can be assigned to them at different levels: site, table, column, and record. Two of the roles that cannot be disabled and exist in all deployments are “authenticated” and “anonymous,” with authenticated status applied to all signed-in users and anonymous to those who are not authenticated. However, some websites allow external users to create accounts, so the authenticated role needs to be treated as one that is external to that organization.

In many of the cases of data exposure that Costello encountered, administrators had assigned global access to a table for both anonymous or authenticated roles in a setup that allowed public registrations on the website. The global access table permission grants access to all rows within a table.

This could be the result of the thinking that column-level access controls are then applied so unauthorized roles can be excluded from seeing any columns that contain potentially sensitive data. However, according to Costello, this feature is almost never used and setting it up is quite involved, unlike in other SaaS platforms, requiring the following steps:

• Within Power Apps, create a catch-all regex so that the column contents will be obfuscated regardless of the value.
• Within Power Pages, enable column security for the column.
• Within the PowerApps Management portal, create a column security profile for the table associated with the column.
• Associate the role(s) of any users you wish to be able to view the plaintext value of the column to the security profile.
• Within the same security profile, create a “read column” permission for that column.

“Throughout the entirety of my testing, not a single implementation of column-level security was present to prevent access to sensitive columns,” Costello said. “Whether this is due to the initially tedious setup duration, or the fact that creating your own regexes is a pre-release feature ‘not intended for production’, this security feature is widely slept upon by organizations.”

A combination of settings leads to data exposure

Data is exposed in Power Pages websites due to a combination of factors. First, the practice of exposing excessive database columns to the Web API, which is not in itself an exposure but can make a potential exposure much worse.

“Organizations that rely heavily on the Web API have a tendency to allow-list all columns of a single table, by setting the value of Webapi/<object>/fields to *,” Costello said. “The result of this configuration is all columns being retrievable by the Web API.”

Another issue is allowing open registration and external authentication, which are enabled by default. The researcher points out that even if the front-end pages are not visible on a website, users could still use the associated APIs to register and authenticate.

Granting global access to tables to external users, whether anonymous or authenticated, with the goal of enabling read operations on a table. This permission results in external users having access to all rows in a table even if the records are owned by other roles.

“If an organization has enabled both external registration and external login, it is important to include the ‘authenticated users’ role in our definition of ‘external users’,” Costello said.

Finally, not taking advantage of the column security profiles for columns that hold sensitive data in addition to the combination of configurations above, means that all columns that are accessible through the Web API will be exposed to external users.

Another thing organizations could do would be to mask or obfuscate sensitive columns for external users without impacting site functionality, but Costello said he hasn’t encountered this practice in his authorized testing.

AppOmni’s report includes a technical proof of concept of a misconfigured website configuration, including examples of requests to tables and columns that were intentionally not exposed to differentiate between API errors and show how to pivot around them.

Mitigation of the Power Pages security gaps

The Power Pages backend displays several warnings when the platform detects a potentially dangerous configuration. For example, on the table permissions configuration page, administrators are warned that using the anonymous role inside table permissions is risky.

Furthermore, any permission that grants global access to the anonymous role will have a warning icon. However, this doesn’t apply to the authenticated role, which, as the researcher pointed out, should be considered an external role on sites that enable self-registration.

Costello advises organizations to audit their Power Pages access controls starting with the site settings, then those for tables and records and then columns. However, he points out that some might not be able to be fixed without breaking existing site functionality.

Here is a list of items to review:

Site Settings

• Webapi/<object>/enabled
• Webapi/<object>/fields
• Authentication/Registration/Enabled
• Authentication/Registration/OpenRegistrationEnabled
• Authentication/Registration/ExternalLoginEnabled
• Authentication/Registration/LocalLoginEnabled
• Authentication/Registration/LocalLoginDeprecated

Table / Record Permissions

• Any table that has the ‘Access Type’ set to ‘Global Access’ and is associated with external roles

Column Permissions

• Any columns belonging to tables that are accessible to external users, which do not have column security enabled and an appropriate mask

Column Security Profiles

• Column security profiles which include external roles

“One common implementation that I’ve noticed is an organization leveraging the Web API on custom authentication forms to validate the existence of a user-submitted employee number, or similar, exists,” Costello said.

“The common misconfiguration here was that there were often excessive privileges granted at both the record level and column level, resulting in complete exposure of the data set. In that case, leveraging a custom API endpoint for validation of user-supplied information would be recommended.”