Who hasn’t felt the pain of having to deal with a clumsy graphical UI when the actual need has been to do a simple “replace all” command to update the underlying text (code)? If you’ve been using Power Platform for an app/automation that needs to be maintained over time, rather than just building net new demo apps, you surely know the feeling.

Just like we know that the cloud is just someone else’s computer, we understand that beneath the citizen developer friendly GUIs that tools like Power Apps and Power Automate offer, there’s a bunch of code. Microsoft manages this layer, and in exchange for your company paying a license fee, provides you with a layer of abstraction that often succeeds in reducing the headaches you need to experience with business apps.

But not always. Sometimes this layer becomes the obstacle for getting things done. Especially when you can “peek” at the underlying code but not modify it directly, it’s very natural to feel the frustration. It’s exactly like on the computer says no sketch from “Little Britain”.

Both the user frustration and the vendor challenges with offering enough control over the interface is not a problem that has a simple solution. With great coding power comes great responsibility. The security aspect in particular is a risky territory for global cloud service providers like Microsoft. Let’s look at a recent security issue discovered in Power Platform that relates to this specific dilemma.

Pretending to be a SharePoint site

Dmitry Lozovoy from Zenity discovered a security hole in the most widely used Power Platform connector: SharePoint. Yes, you’re surely using it, and you can’t even block it with the current DLP features of the platform. It’s from Microsoft and it’s a foundational service that has been with Power Platform before it was even called that. It would be logical for you to assume that MS internal security folks would have poked at the connector long enough to identify common gaps.

Well, turns out that an SSRF vulnerability existed in the SharePoint connector. What is “SSRF”? I admit I didn’t know the term either, so I do what any normal person does today and ask your friendly AI assistant to explain it to them. In short, Server-Side Request Forgery means that the attacker can trick the server to send or fetch data from a URL that it shouldn’t communicate with. Let’s say that a specific Power Platform service managed by MS should only communicate with URLs that end with “microsoft.com”. Now, being the clever hacker that I am, using SSRF I can get that service to talk with a “jukkaniiranen.com” URL instead. Meaning I can read data I shouldn’t see or serve data that Power Platform thinks is secure.

Sounds quite simple now. Surely this is blocked by big cloud vendors by default. At least ChatGPT agreed with me when I asked about this:

The caveat is of course the level of configurability that users have in the system. In this case, the user means the attacker who would have found a way to either deploy or get someone else to deploy a Power Platform solution that exploits SSRF vulnerabilities. ChatGPT can easily detect where the risk lies in such scenarios: the input of external URLs into cloud flows making HTTP requests:

Turns out this isn’t only an issue with the HTTP connectors, but rather with a first-party Microsoft connector. As Dmitry said:

Here we have it. Users were able to “edit the code” for the connector, by inserting values directly into the Site Address parameter of a Power Automate cloud flow. They didn’t have to pick it from a dropdown field with prefiltered values provided by Microsoft. As a result, the URL could point to any site in the world, SharePoint or not:

Is this a big deal, though? Looks like standard stuff that a low-code maker would be working with. Which it of course is. Except that from the perspective of Microsoft, they are incorrectly assuming that it’s safe to communicate with the user provided URL. At least safe enough to send the user’s token to it:

Whose token is it? Well, initially it’s the one by the maker of the cloud flow. But knowing how Power Platform works and what the user experience for the end-users interacting with it can be like - you can leverage this method for collecting SharePoint authentication tokens from people interacting with Power Apps, for example. This is what Dmitri demonstrates in his video:

There are a lot of details in this scenario to digest. Let’s take it up a level and talk about the general issue with connections management in Power Platform next.

Credentials sharing as a service

Last year I wrote about the security dilemma of low-code. It focused on the layer that we as Power Platform makers or admins don’t often see at all - because presumably Microsoft intentionally makes it hard to observe: connections stored inside the platform.

Subscribe to Plus to read the rest.