INVALID_FORMID issues when using Safari + LastPass MacOS OR Chrome + Google voice

[Sillymak]

We are seeing unexpected errors when using a combo of:

• Safari v 16
• LastPass 4.101.2
• LDAP connected
• (we've determined that OAuth is not affecting this problem)

When a user tries to updateprofile by clicking on the tile, or navigating directly to /pwm/private/updateprofile, the presence of lastpass seems to be causing sessions to be dropped or not communicated, for unknown reasons.

The user does land on the /updateprofile module page to enter their password, but any attempt to submit the password to bind to LDAP results in "Service is not enabled" error.

I suspect something is happening to either the JS on the page, or some combo of cookie suppression. But the end result is that the FORM POST is incorrect or rejected.

Disabling LastPass options across the board does not fix this. Neither does adding our pwm domain to "Never do anything" settings in last pass. The ONLY thing that seems to work is completely disabling the LastPass extension in Safari preferences.

[Sillymak]

We've discovered a related attribute that helps narrow the problem: when "Enable Form Nonce" is disabled, Safari+Lastpass works, regardless of SSO configuration. SSO does not seem to affect this problem.

So whatever is happening with Form Nonce validation is breaking when safari + lastpass are used.

[Sillymak]

We've found another combination that is causing INVALID_FORMID errors.

We have some users with Chrome + google voice extension running and they are also seeing problems with the PWM form nonce feature.

[Sillymak]

After more investigation, we determined one of the triggers for the error with Google Voice to be the default CSP policy blocking loading of the images the GV extension loads from gstatic.com. When we added a image-src whitelist entry in the CSP for gstatic.com the problems could not be reproduced.

However this highlights that SOMETHING is wrong in the form nonce processing logic in the Angular frontend. CSP violations are normal, but they should NOT break the local app behavior. Nor should they require adding CSP entries just to not break the form nonce logic.

In the long run I think if the form nonce logic was fixed so that CSP violations did NOT break them, the PWM app will be a much more robust application.