Web Security in Portals - owasp recommendations

(1) Share

Report

Posted on by Christian Leverenz

1,214

Hi together,

i have questions about the general security of sites implemented with portals. We are implementing a kind of registration site which is a little bit complex and requires more than one step. We can not use advanced forms and use basic forms and pass the id of the data which is just edited from page to page with a get-parameter, so pretty much what everybody would do 🙂

Amongst others, my clients are concerned mostly about the following three things:

when the url of this process is somehow stolen, another person can work on the same entity just by knowing this id.
In the former version (which was adx with backend code) we just set a cookie in the very first page with a checksum and on each on and every request we could check, whether the request came from the same browser.
I have no idea how to set cookies from PowerApps portals now.
Are there some people out there who also have to make sure, that consecutive requests come from the same browser? How do you achieve that?
We make heavy use of the webapi. This raises also a security issues: a person having know how of portals could just by gussing the attribute names spoil our process, because the api can be used from the console with no problems.
Does anybody have an idea to prevent this? (i think its not possible by design and all websites which make use of their own api have this problem)
Is there any documentation around which describes, whether portals are somehow vulnerable to DenialOfService attacks or other approaches? Is there any documentation around, whether the mechanisms and detections of azure apply to portals as well and the webserver is therefor somehow safe?

Any ideas and thoughts about this topics are highly appreciated

Thanks a lot,

Christian

Categories:

Power Apps portals

I have the same question (0)

All responses (3)

Answers (1)

Christian Leverenz 1,214 on at

Like (0)

Report

Hi together,
meanwhile i got an answer from Microsoft to part of this:

I was told, that Microsoft ensures Basic DDoS Protection on all Portal environments. I would have guessed so, but it is good to have it confirmed (well, yes, sort of inofficial but my client is ok with that).

Another idea is to set up a WAF for the portal like described here: https://docs.microsoft.com/en-us/powerapps/maker/portals/azure-front-door#set-up-the-azure-front-door-endpoint-and-custom-domain-name . Shame on me, that i did not have that idea.
This approach could also solve many other issues like blocking specific paths from specific locations or rate limiting requests (could also be done via api-managemant). The idea behind this to broaden your view on the infrastructure.

I have no idea about the costs, but this is definitely something i am going to look at.

Hope this helps a little bit,
Christian

Was this reply helpful? Yes No
Verified answer

oliver.rodrigues 9,368 Most Valuable Professional on at

Like (1)

Report
A few points here:

Guessing the GUID of a record wouldn't be that simple, I think you can let your customer know that GUIDs are not like a sequential number and not anyone will just guess a correct GUID

You can add cookies / session values via JavaScript if you want additional validation

Definitely enable WAF as that can increase security

Other steps you can take:

I always to try to convince customers to stay away from allowing personal data input while unauthenticated

I have implemented a few times a simple authentication process, where users are given a Web Role that will only let them fill an onboarding/registration form

Then once approved they receive another Web Role that will give them access to more functionalities of the Portal

Was this reply helpful? Yes No
Christian Leverenz 1,214 on at

Like (1)

Report

Hi @OliverRodrigues ,
thats right, thanks. In fact, it is a site where users sign up for a service, so this is the exact case. Guessing is not esay, but stealing or sending via email is possible.
The setting of a cookie via javascript could be an option but is only on the clientside. So, one could also set something in other storageplaces in the browser. But yes, can be done.
The documentation says, that request.params will also carry cookies. Will try that out 🙂

In fact, when the user really sends the data at the end, the entity is blocked from beeing shown in the portal by checking the statecode/statuscode in liquid. And unfinished signupos are deleted after a while. So, its a minimum vulnerability.

Nevertheless: good to know, that its not only me caring for data security in portals - thanks for commenting.

Have fun,
Christian

Was this reply helpful? Yes No