18
Views
2
Comments
Inconsistent behavior between Registered and Custom roles

Update:

After some more thorough testing of the "Registered" and "Custom" role validation, using the built-in CheckXRole action, their output seems to be consistent when a request is made through Postman. If a request is copied from the Network tab inside the Dev Tools, as a CURL command, and pasted into Postman, the CheckXRole still returns 'True' and doesn't trigger the 'no role' exception (I assume it is because the entire request's headers are also part of the same CURL command.


Does this pose any security threats that need to be addressed? Not a cyber security expert here, just trying to better understand the implications of this on security of applications and such :)

                                                                                                                                                                                                

Hi, 


I was doing some security validation testing, out of curiosity, and I encountered an unexpected behavior when validating a user's role on the server side before CRUD operations. 

1. Registered Role:

I was validating whether the user has a Registered role before performing any request. From the application itself, there were no issues whatsoever, it worked as expected.

I then intercepted the service action request from the browser and mimicked the same request using Postman, the server validation failed to block this request.


2. Custom Role:

I created a new custom role and adjusted the logic to check whether the user has the custom role assigned to him, instead of validating whether he's registered or not.

However, when I performed the same test from Postman, the flow behaved as anticipated, triggered the "Not Custom Role" exception and hence blocked that request.

I'm confused by why this discrepancy occurs with the "Registered" role. Shouldn't the validation flow be consistent in both cases? Why does it only raise an exception with the custom roles?


Any insights into this behavior would be greatly appreciated. Thanks in advance! :)


Best regards,

Abed

2020-09-15 13-07-23
Kilian Hekhuis
 
MVP

Hi Abed,

I may not understand what you are doing exactly, but "Registered" just means "the user is logged in". If the user is logged in, CheckRegisteredRole will return True for HasRole, and if the user is not logged in it will return False.

2024-01-04 15-15-51
Abed Al Banna

Hi @Kilian Hekhuis,

Thank you for your reply :) I am aware of how the CheckXRole works inside an OutSystems application, the issue that I am facing is regarding mimicking the requests made from the browser, using Postman or a similar web client.

From a normal user's perspective, using an app from a browser, the role validation seems to work just fine. If a user has no permission to perform an action, that is validated in the server side, an exception is always raised.

However, using DevTools, it is possible to inspect the requests made by the application under the Network section, copy that request as CURL and paste it in Postman which in turn invokes that request. Doing so, the user role validation is bypassed in the server side as the CheckXRole is always returning 'True' (I assume it is because the CURL command also contains the request token?), and the logic is executed normally when it should have gotten blocked.

I am trying to learn more about how to secure apps, I am uncertain about the risks this would have on applications, but it seems like it is something that can be exploited if a malicious user somehow gets hold of that CURL (be it through malicious attacks or by a legitimate user simply sharing the copied CURL command from the browser).

Any idea how this works under the hood, and if it's possible to mitigate this risk of forging requests using Postman? I might be missing the bigger picture here...


Thanks in advance!

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.