Question
BPM Company
NL
Last activity: 12 Apr 2024 12:43 EDT
Surpressing (database)exception in http response in SAML SSO
I'm looking into a finding where a HTTP GET-request was done to the SSO URL of our Pega application, a database-exception was happening and this got returned in the HTTP response body showing all details like the INSERT-query and the values.
I'm not able to reproduce the issue but I would guess there's a setting to surpress exceptions from coming back in the HTTP request.
I checked the security DSS on Understanding dynamic system settings | Pega but don't see an explicit one.
prconfig/alerts/database/operationTimeThreshold/suppressInserts/default seems related but surpresses what goes to the log.
Are there 1 or more relevant settings/configuration/DSS to surpress exception details to be returned in the HTTP response?
Accepted Solution
Updated: 12 Apr 2024 12:43 EDT
Pegasystems Inc.
IT
Hello @MaartenBPM and @MarijeSchillern The DisplayExceptionTraceback DSS should do the job, If this is not the case I would recommend creating a Support Incident, attaching the whole message returned back to the client, including the stacktrace of the exception and the message text (with any sensitive and PII data redacted please), so that the issue can be investigated more in depth. An alternate solution, is to configure the Servlet Container to avoid returning detailed HTML error page. For instance, in Tomcat this can be done by either configuring the Error Valve or by providing custom error pages in application web.xml deployment descriptor. Please engage your sysAdmin to figure out the approach that is more suitable in your case. Thanks
Updated: 3 Apr 2024 16:15 EDT
Pegasystems Inc.
GB
@MaartenBPM Info found via a GenAI search:
The prconfig/initialization/DisplayExceptionTraceback/default DSS can be used to prevent the display of stack-trace when an error occurs. However, there is no explicit setting mentioned in the provided context that suppresses exception details from being returned in the HTTP response.
🌕 Suppressing sensitive data in alerts
🌕 Understanding dynamic system settings > Dynamic system setting information
@DomenicoGiffone is this perhaps a question you could help answer?
BPM Company
NL
@MarijeSchillern Thanks for your answer and looking it up.The DSS prconfig/initialization/DisplayExceptionTraceback/default was already existent on all environments and set to false, on stg1 it was installed long time ago and pxCommitDateTime is 2022. So unfortunately it didn't avoid the exception from coming back in the HTTP response.
The other DSS in the links like prconfig/alerts/database/operationTimeThreshold/suppressInserts/default suppress details for going into the alert log but don't relate to HTTP response.
I hope that @DomenicoGiffone can help answer this one then.
Accepted Solution
Updated: 12 Apr 2024 12:43 EDT
Pegasystems Inc.
IT
Hello @MaartenBPM and @MarijeSchillern The DisplayExceptionTraceback DSS should do the job, If this is not the case I would recommend creating a Support Incident, attaching the whole message returned back to the client, including the stacktrace of the exception and the message text (with any sensitive and PII data redacted please), so that the issue can be investigated more in depth. An alternate solution, is to configure the Servlet Container to avoid returning detailed HTML error page. For instance, in Tomcat this can be done by either configuring the Error Valve or by providing custom error pages in application web.xml deployment descriptor. Please engage your sysAdmin to figure out the approach that is more suitable in your case. Thanks