Question
Tech Mahindra
CA
Last activity: 4 Oct 2024 6:43 EDT
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.
https://support.pega.com/question/access-when-click-links-navigationmenu
Regards,
Naveen
·***Edited by Moderator Marije to add closed Case INC-247357 tags***
Accepted Solution
Updated: 4 Oct 2024 6:43 EDT
Pegasystems Inc.
GB
@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.
@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:
Verifying requests when using custom controls
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.
NCS Pte. Ltd
SG
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.
TCS
IN
@NaveenReddyMekala This is off topic here, did you found the solution for https://support.pega.com/question/there-any-pega-libraries-available-or-any-other-means-extract-blob-readable-format-could
Our client is also looking for the same, it would be very helpful if you can post your solution for the above query.
BNY Mellon
IN
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.
Accepted Solution
Updated: 4 Oct 2024 6:43 EDT
Pegasystems Inc.
GB
@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.
@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:
Verifying requests when using custom controls
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.