Power Platform solution hacked?
Perhaps the title of this blog is a little (intentionally) contentious but… I had an interesting conversations with one of my colleagues, Andrew, recently. It went a bit like this (but it’s a bit dramatised for fun :D)….
Andrew : SIMON! MY FLOW HAS BEEN HACKED!!!
Simon : WHAT?!
A: There has been a breach with data being created outside of controls! I don’t know how they did it! This is a threat to national security!!!
S: Slow down! Tell me what happened!
A: They’re booking desks outside of the 3 week permitted window! Chaos! It’s going to be chaos!!!
S: stunned silence Let’s… let’s look into it and see what’s going on! I don’t understand what could be going on… Talk me through it.
It wasn’t as dramatic as that really but my colleague talked me through his solution. We didn’t know what was going on but he described the scenario…
Image describing data being filled in in a Power App, it triggering a Flow that put the data into a Data Source
The solution was this - It was a desk booking app. The user would use a Canvas App to choose a date, a desk, and book it. The booking had to be within a 3 week window so there was validation logic in the ‘Book’ button to check that the date was less than 3 weeks from today and only if it was would it allow the button to be pressed.
The button was pressed and a Flow triggered that would use a Service account to take the Person, Date, and Desk details and put it into a data source (in this case a SharePoint list). Only the Service Account had access and permissions to the data source - no end users could interact with the data source.
Diagram showing the issues that had been spotted where bookings were being logged outside of the 3 week validation period
However the solution wasn’t being used as planned. Somehow there were entries in the data source that went out past the permitted 3 week booking period… We couldn’t work out why… After some investigation Andrew found how it was done…. The entries were from 2 specific people… They had found out that…
From the browser tools they could see what activities were being carried out by the App. One of these was an ‘Invoke’ activity where the Date and Desk ID values were being passed to the Flow triggered from the App.
It was possible to edit these values and then re-submit the 'invoke’ action and the values would just get put into the data source as they were of the right data type. Because the validation logic took place in the App the Flow just happily did it’s job and put the data where it was supposed to go!
We were surprised to say the least that this could be done and although we saw some immediate fixes that could be implemented to move the validation logic to the Flow we wondered how many other people were unaware of the risk and conversely the design practices that could manage the risk.
Design practices that could be used on this scenario to manage various data security risks
To help highlight some of the solution design practices that mitigate different risks around this type of scenario I’ve highlighted these on the above diagram - These include Technology, Process, and People, elements such as:
Technology
Using the principle of least privilege to ensure only the right people and accounts, have the right access and permissions to solution and data.
We think about where we best put data validation logic to put the right controls in place and that they can’t be worked around.
How we architect a solution to abstract the user from the data to ensure that there is a gap between what the user is doing, and the data management processes - these could be by using Flows acting as services, or perhaps something like a Service Bus.
Process
Implementing data review / audit processes to trigger housekeeping activities. These could be manual to start with but could also be automated. They could have reporting associated with them too.
People
We could document user responsibilities to ensure they know how we expect them to interact with the solution
We can remind people about any of the org’s policies or procedures that describe how data and systems should be used.
We should also keep an eye on our sneakier of users… Where we have people testing the boundaries of our solutions like this let’s try to build relationships with them and bring them closer to help us highlight and mitigate these scenarios!
Is this risk scenario something you’ve encountered yourself? I’d love to hear your experiences and ideas around solution and data security and controls to mitigate these sort of risks.
