Hi,
I have received the following findings from the penetration test report,
"A malicious user with a way to obtain a valid __OSVstate would be able to directly retrieve or modify sensitive documents from all application via this method"
The report has the following recommendations too,
"Apply access control checks onto the data objects themselves such that only authorized users and roles would be able to access the protected resources"
A quick background (I am not able to share the module as this is my company project),
There are like, 2 users with different access rights to a single screen. In our module preparation, we had a "CheckPermission" server action to check the access rights already. So when we open 2 browser (1 of them being a incognito browser), and log in with the 2 different users, the UI are being displayed correct. Ie. User 1 can access the page, and User 2 can't.
However, in the User 1 screen, when we click on a button, example 'Reset', to refresh the page, this will trigger a HTTP request. Now when we copy this HTTP request (OSVstate), and replay it using User 2 session, it is possible to access the screen.
Think the testers had done this using postman or something...so even thou my UI is still displaying correctly, i tried to manually key in the URL for User 2 and access is denied, this issue is still being raised up.
We are not allowed to install Forge component, as such, most likely one of the resolution is to keep adding the CheckPermission or CheckUserID action in the preparation of almost all the screens, screen actions, web block, links etc
Has anybody faced this same issue, or are there any 'correct' ways to handle this?
I have also read this link in documentation, and saw this sentence,
"Avoid performing validations only in Preparation. If using old page or screen values (for example, having a second tab open, or in case the user clicks the back button on the browser), the server must validate if the actions can still apply instead of relying on information calculated in the Preparation "
Could this be the answer I am looking for? If so, I had understand it as adding the validation check in almost all my server actions in the Core module.
Any help or advise will be greatly appreciated!
Thank you.
Regarding osviewstate, you can encrypt this, it is documented here:
https://success.outsystems.com/Documentation/11/Managing_the_Applications_Lifecycle/Secure_the_Applications/Encrypt_web_apps_view_state
Regarding the screen accessible by multiple roles, you could consider refactoring this in a screen per role. This is by far the safest way. Shared structure and content on the screens, you could refactor in web blocks for reusability.
Regarding validations, it is always good that you validate access to read, write and delete based on roles. If the role is not allowed to read, write or delete data, a no permission exception should be fired.
Regards,
Daniel
Hi Daniel,
Thank you for your response. Yup, my company do has the Encrypt Viewstate ticked. But the pen tester still manage to access it.
The way my company structure the screen, is we do have different web blocks in the same screen. And we have to check for their permission and role prior to allowing access (whether to view, or click to go to another screen). So when we are trying this out in the browser, everything works as per expected. Until the pen tester comes in....
So what we did now, after advise from a team-mate, is that we do a 'CheckPermission', 'CheckRole' etc in all the preparations, whether screens or web blocks. We even added these checks to 'links', 'buttons' etc
We are going to submit this for another penetration test soon. Hopefully things will turn out well.
Thank you
Of course anybody can access the browser devtools and access the viewstate, but if it is encrypted, that what can the pentester or hacker do with it? how was he able to manipulate the viewstate such that he could let the application behave unintended?
I do have no idea what the pen tester did to manipulate the viewstate. However they are able to do it, so this came up such a finding for us to fix.
We were testing on the min/max access test to the screen, and some users should be able to see all of it, while some users can only see part of it, and/or can't click any buttons/links etc
Anyway, we have almost completed adding the CheckPermission or CheckRole to most of the web blocks, buttons etc.
Will definitely update once they run the pen test again
A quick update, after adding CheckPermission to all screen preparations, web block preparations, buttons, links etc, we have clear the pen test findings :)
Thou we still find the solution very extensive and not practical.
As we have another module to be send for pen test soon, we will be doing things differently, and see if it will helps.
Thanks!
If you have some many checks on a role permission in a screen, you should consider to refactor to screens per role. Your screen logic would be much simplified and easier to maintain probably still less work than having all logic in one screen.