Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Setting “prconfig/setSecureCookie” still allows sniffer program

SA-1324

Summary



Based on the “setSecureCookie” description in the PRPC config help:

SetSecureCookie 
Type: boolean 

Default: False 


Functionality: 
This setting indicates whether to set the “secure” flag on the cookie itself. If this flag is set, then the cookie will only be sent from the client to the server if the browser is using a secure protocol – i.e., using either https or SSL. If the browser is not using a secure protocol, then the cookie is not sent. 

If the server does not receive a cookie with a request, it assumes that this user does not have a requestor and sends back the logon screen. Note that even if the user re-logs on, if there is no cookie included in any of the browser requests (due to not using either https or SSL), the user will continue to only get the login screen as a response. 

This security is provided in case a hacker uses a “sniffer” program on the network line. If this entry is set to false (i.e., not secure), then the “sniffer” will display the cookie requestor information in clear text. If the entry is set to true, then the data in the cookie will be obfuscated. 

Available Since: Version 5.3 SP1 

When a “setSecureCookie” is enabled, the data contained within the cookie would be obfuscated. However, this is not true during testing. Also note that this is being set from DynamicSystemSettings configuration.

Plain text data can be seen in the cookie when cookie is captured on Fiddler trace.


Error Messages



NA


Steps to Reproduce



NA


Root Cause



This is expected behaviour. When using HTTPS, the data is encrypted. Using Fiddler, we're deliberately decrypting the session, which is not the norm for normal connections. Using a simple Wireshark trace, the cookie data is not visible when on HTTPS.



Resolution



The explanation for this behavior is as follows: 

The secure cookie means it'll only be transmitted on SSL session, hence cannot be intercepted.
It is not necessary to obfuscate the cookie as it is already on HTTPS.

Published January 31, 2016 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us