Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user's Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.
Posted: 5 years ago
Updated: 5 years ago
Posted: 27 Nov 2015 4:25 EST Updated: 27 Nov 2015 4:26 EST
But I see 2 Support Articles which say that --> CSRFAttack is due to a new parameter introduced as a part of Pega 7.X Upgrade, etc. Can someone advise if this is a Pega BUG ? Sorry to mix-up these two issues. As for our customer application, we are observing many WARN LOGS which are mentioned in these both Support Articles - CSRFAttack Invalid harness ID, CSRFAttack Missing harness ID.
You can change the prconfig settings that Arvind describes above. I would recommend, in a non-production environment, looking into why you are getting the warnings in the first place, in my experience resaving or updating old rules that are tripping the warning not makes the warning go away but it also helps eliminate potential security holes. We (SpyVsSpy) did this with PMF a few months back.
Thanks Matthew Morency for the reply. I did verified this setting but could not able to find the configuration in Prconfig & as well as DSS. Looks like this setting is not defined in our application bust still we see these WARN & ALERT Messages. Can you please advise further ?
Also, not sure why we are seeing these messages only after Pega 7 Uplift. Any clue ?
I have pasted the documentation on the settings below, you may need to restart to have them take effect:
The following dynamic system settings have been introduced to address the CSRF issue
security/csrf/securedActivities – comma separated list; The format for list of activities would be Data-Admin-Operator-ID.AddNewOperator, PegaAccel-Task-GenerateApp.CreateAllOperatorIds, Data-Admin-.pzCreateOperator
security/csrf/securedStreams - comma separated list; The format for the list of streams would be @baseclass.ActionPreviousOperator, @baseclass.Operator-MenuPassword
(It is better to avoid the classnames which only means more coverage.)
security/csrf/validreferers - comma separated host names. This setting specifies the valid referers the incoming requests can have. sample value: http://wrupaaw7,http://wrupaaw7:8080
security/csrf/mitigation - the switch used to toggle the "CSRF mitigation using referer validation" feature on or off. Default value is FALSE sample value: TRUE
security/csrf/secureall - Indicates that all activities and streams are secured – no exceptions.
AES alert with code SECU0008 would be raised for the CSRF attack suspects
Using the security/csrf/secureall=true as it is too restrictive.For the list of secured activites, it is recommended to utilize the SQL below to identify those needing to be added to the setting. Primarily though you need to secure activities that can be triggered by a user or have 'May Start' checked. Depending on the number of activities in the system this could be a large entry in the DSS.To determine what activities qualify you can run a query similar to this:
Selectdistinct(pyrulename) from rulesschema.pr4_rule where pxobjclass='Rule-Obj-Activity'and PYRULEAVAILABLE in ('Yes','Final') and PYINPUTMAYSTART = 'true'
The cross site scripting alerts in 717 are a huge problem when running CPM. Frankly, it does not work - we generate thousands of false positive SECU0008 warnings. Unless someone takes time and effort to do full regression test on Pega applications to develop the 'whitelist' its better to disable the SECU0008 alerts at customer sites - especially since we have no information on PDN on what to do with a SECU0008 and AES does not provide any advice. As of 719 and AES 717, SECU0008 alerts are at best a huge distraction
In-case if we need to whitelist the Streams & Activities that need to be secured, it will be a huge number (definitely in thousands) for the Big Financial Institutions using Pega/CPM (just like as our customer ).
Yes, Andrew's point is correct ! Most of them would be false alerts also. As CCP's log-into our application & use the Portal in a most secured way (SSO) but still we see these Alerts/WARN Messages as when they navigate to different screens in the Portal. When we consider all Production Nodes, we are observing 1,53,000 SECU0008 Alerts on a Peak Business Day which we want to either -- get rid-off OR eliminate OR need to fix.
As I mentioned earlier not able to find any security configurations defined in either DSS nor prconfig. Not sure how this can be TURNED OFF ??
Try dynamic system setting Pega-Engine.prconfig/security/urlaccessmode/default
See SR-A11177 - waiting to see impact of this setting on a very large CPM system
believe the notes in SR (from my email not gcssupport) are ...
A defect in Pegasystems’ code or rules The messages are due to a bug in 7.1.7 with a new CSRF defense mechanism that we have seen on other systems as well. It is not a true CSRF attack. Unfortunately, these messages are triggered by some normal system operations on some applications. This bug is slated to be corrected in an upcoming release.
Perform the following local-change: You can completely disable this defense (and the messages) using prconfig or DASS: DASS: Pega-Engine * security/urlaccessmode with a value of "allow" prconfig: <env name="security/urlaccessmode" value="allow" />