Vertical Privilege Escalation/ unauthorized access vulnerability while using navigation rule

Hi,

We have an issue reported by security team that a user with lower access can access unauthorized harness by intercepting and manipulating the request. We use privilege for visible condition in navigation rule to restrict particular option for user on portal. “pega.desktop.showHarness” script is called by passing harness name on clicking menu option. After intercepting the request by security team for an option, they altered harness name to an unauthorized one, and harness is displayed without any issue.

We are in Pega 8.6.4. Please advise how to apply restriction here?

I’ve gone through the below post but no clue what to do.

Regards,

Naveen

Hi @NaveenReddyMekala: One workaround is to add a visibility condition / privilege to the sections included in the harness.

But I would like to hear from PEGA too if this is the intended solution.

Dear Moderator team: Can you help on this. The other article speaks about a hotfix but it has no details of hotfix.

Thanks.

@NaveenReddyMekala This is off topic here, did you found the solution for Is there any pega libraries available or any other means to extract the BLOB into a readable format (could be XML) without using pega application? | Support Center

Our client is also looking for the same, it would be very helpful if you can post your solution for the above query.

Hi @NaveenReddyMekala , Did you get any solution or response for this issue? We are currently facing the same issue.

Moderator Team, Can someone please guide us here.

@VenkateshKumarR6041 I have spent some time researching this for you. Naveen logged a support ticket INC-247357 a week after posting the question on the forum.

The issue came down to the configuration of BAC not having been set as per the documentation:

Verify requests at the application layer

Both pyShowSecureFeatureWarnings and pyBlockUnregisteredRequests were set to false.

Root cause description:

We have an issue reported by security team that a user with lower access can access unauthorized harness by intercepting and manipulating the request. We use privilege for visible condition in navigation rule to restrict particular option for user on portal. “pega.desktop.showHarness” script is called by passing harness name on clicking menu option. After intercepting the request by security team for an option, they altered harness name to an unauthorized one, and harness is displayed without any issue.

Solution description:

Set pyBlockUnregisteredRequests to true. You can leave pyShowSecureFeatureWarnings as false.

pyBlockUnregisteredRequests is set to false by default so unregistered requests are processed normally. This default behavior allows your application to behave as expected while you work on configuring your custom control.

The best way to secure your custom controls is to register your unregistered code and set pyBlockUnregisteredRequests to true. There is no alternate solution. Keeping the When rule pyBlockUnregisteredRequests set to false in long-term is not recommended, especially for production. Ideally, it is kept true in development environments as well so you can detect the issues and register them as they come up.

NOTE: If you use custom activities for ReloadHarness and ReloadSection, you must register these custom activities in a permit list after applying the remediation. See Verifying requests when using custom controls to learn more about registering custom activities and controls.

Documentation for configuring custom controls:

https://docs-previous.pega.com/security/86/verifying-requests-when-using-custom-controls

https://docs-previous.pega.com/security/86/configuring-custom-control-registering-action-page-java

For the latest documentation please use the docs.pega.com server:

Using Access Control Checks

Security Checklist core tasks

Verifying requests when using custom controls

Security Checklist

Security Bulletins

As always, we recommend our clients review the Pega Platform Security Checklist regularly.

Naveen’s issue was resolved via the INC: The final solution involved going with a section level visible condition as they were not able to set pyBlockUnregisteredRequests to true.

I will mark this as the Accepted Solution as this question was posted 2 years ago.

If any users have questions relating to similar symptoms mentioned here, please create a new post on the forum by using the Ask a Question menu.