SEC0019 Alert

Hi,

We identified lot of SEC0019 alerts are being logged in PDC. All these alerts are pointing out to PEGA OOTB activities. We want to have a fix to the root cause rather than blocking such kind of alerts.We also want to know why these alerts are being generated. Is it related to our Application security issue? or PEGA OOTB related issue? Please share any solution how to fix this issue.

Thank you!!

Here is sample Log query:-

2023-02-07 06:56:21,719 GMT8SECU0019002075ca1b96c5e278987b4ba4b0dc7808NANAHZ4DYYKALOVZSNDNNIN3L50ZE0P4LIQZEAP821370DNAB-UWF-Worknull5f1179955d38ea7a73b73fec5843e00fY322HZ4DYYKALOVZSNDNNIN3L50ZE0P4LIQZEA5476https-jsse-nio-8443-exec-144TABTHREAD2com.pega.pegarules.session.internal.engineinterface.service.HttpAPIuat4.pega.extnp.national.com.au|10.157.188.23Activity=pzUnsubscribeFromPushRule-Obj-Activity:pzUnsubscribeFromPush*@BASECLASS PZUNSUBSCRIBEFROMPUSH #20180713T133301.511 GMT Step: 2 Circum: 00NANANANANANAinitial Executable;0 additional frames in stack;NAUnauthorized request detected : Unregistered request encountered for activity Open

@AkhilReddyP16751743 Hi,

Can you please look into the below links and let us know if that helps:

Secu0019, Security

If not then you might need to check if there are any hotfixes already available for this issue.

@AkhilReddyP16751743 You can stop “push subscription” by DSS setting below and restart.
Owning Ruleset: Pega-Engine
Purpose: prconfig/server-push/enabled/default
value: false

The security alert SECU0019 is generated when a control issues a request that has not been registered. In Pega Platform™ 8.3, the message was erroneously logged as SECU0006 (although the message text was correct), but the alert code has been corrected to SECU0019 in version 8.4.

For more information, see Verifying requests at the application layer.

SECU0019 alert: Unauthorized request detected

Pega Platform™ protects access to information in your application by using role-based settings and access control policies. Pega Platform provides additional request verification when you use autogenerated controls. As a best practice, and to conform to platform guardrails, use autogenerated controls. You can manually configure custom (non-autogenerated) controls for increased security.

The article Verifying requests when using custom controls describes how to manually configure non-autogenerated controls.

You can verify requests at the application level by using three when rules, which are defined on @baseclass. You can override these when rules in your application.

pySecureFeatures should control Application level checking when is false, The other two when conditions- pyShowSecureFeatureWarnings and pyBlockUnregisteredRequests will work as expected.

Note:

When pySecureFeatures is false, no access checking is performed and the other two when rules are ignored.

Logs will be logged whether you make pzSecureFeatures as false or true.

You have asked for a “solution how to fix this issue.”

This URL tampering check is latest feature added to Pega. So it will be fixed in latest rule i.e, Theme Cosmos .

See our documentation on possible reasons why these alerts are generated:

Registering the action and preventing the security alert

@SrinidhiM Hi,

I have already looked into these links, couldn’t find any reasonable solution.

Looking for hotfix as of now.Kindly. post here if you find out something.

Thank you!!

@MarijeSchillern Hi,

I have gone through Verifying requests when using custom controls | Pega , found out how to identify custom controls in an application by running "pzPopulateRulesWithActions" activity. But when I run this activity it is failing to generate spreadsheet.

I have one more query regarding stopping “push subscription” by DSS setting. Is it PEGA recommended? will there be any other impacts?

I deeply appreciate your help here,Thank you!!