Disable sessionFingerprint by default

[apeisa]

Short description of the issue

Dynamic IPs are very common. Having session's tied to IP-address make very hard to debug problems with things like long Form Builder forms (or any other form that uses CSRF-tokens).

I am only suggesting changing the default behavior for new sites.

Expected behavior

It should be possible to submit long forms even when your IP address change while populating the form.

Actual behavior

If your form uses CSRF-tokens (like it often should) and if your client has dynamic ip, current default behaviour make your submit fail.

[ryancramerdesign]

I'm not sure we'd want to disable a core session security feature to accommodate FormBuilder. Perhaps FormBuilder could alter the session fingerprint setting or provide a config option to adjust it? There's these other options for fingerprint, maybe 8 would solve it in FormBuilder, rather than disabling fingerprint?

• 0 or false: Fingerprint off
• 1 or true: Fingerprint on with default/recommended setting (currently 10).
• 2: Fingerprint only the remote IP
• 4: Fingerprint only the forwarded/client IP (can be spoofed)
• 8: Fingerprint only the useragent
• 10: Fingerprint the remote IP and useragent (default)
• 12: Fingerprint the forwarded/client IP and useragent
• 14: Fingerprint the remote IP, forwarded/client IP and useragent (all).

[teppokoivula]

+1 for "... or provide a config option to adjust it". This issue has occurred multiple times for us, but I would still absolutely hate to see an important security feature like this turned off by default. Also a module disabling it without user consent is not the right way to go, in my opinion :)

[ryancramerdesign]

Technically there already is a config option to adjust it, $config->sessionFingerprint, but I was thinking maybe it's something that could be adjusted in FormBuilder module settings or form settings. We do already have a setting that disables it (form settings tab), but it also disables CSRF.

[teppokoivula]

Just for the record, I'm aware of $config->sessionFingerprint. We're talking about the same thing here. Even though there is indeed a global setting for it, in my opinion it would still make sense to point out via FormBuilder module settings that this could be a potential problem.

That being said, it might also make sense to just check $config->sessionFingerprint and then display a warning message and point out which setting would be preferable for FormBuilder?

Unless, of course, we only want to change it when FormBuilder or a specific form is loaded.. :)

[ryancramerdesign]

It doesn't look like we could disable this on a per-form basis. The session is initialized before any page (or form) is rendered, and the fingerprint would need to be adjusted before the session starts. FormBuilder would have to disable it in its __construct() method, before any form settings can be known, and before even module settings are known. I don't think FormBuilder should override what's intended to be a user configurable setting. Probably best bet is to mention this in the documentation and maybe provide a notice about it on the Embed tab, so that it can be considered when adding a form to a website.

[netcarver]

@apeisa @ryancramerdesign Bumping this to bring it back on the radar, as it is well down in the list of issues.

[ryancramerdesign]

@apeisa @teppokoivula Are you guys still observing issues with the default session fingerprint setting? I've not heard of fingerprint issues since this issue report from 2 years ago, so am reluctant to change the default/secure setting, but let me know if you think this is still something that we need to change? Thanks.

[teppokoivula]

I don't currently work on any ProcessWire client sites, but if my memory serves me right, back in the day we dealt with this issue by always manually disabling the CSRF protection for all new FormBuilder forms, and instructing clients to do the same. When they forgot to do that, submissions would start randomly failing.

In the case of FormBuilder I can see two relatively non-obtrusive solutions that would at least improve the situation:

• Provide an option in FormBuilder for disabling CSRF protection for new forms by default.
• Identify the CSRF setting in FormBuilder when editing a form, and show a warning if CSRF protection is enabled, explaining to the user that this particular combination may be problematic.

Obviously that doesn't solve the issue anywhere else. I'm not really sure how to approach this issue in other situations – perhaps leave it to the developer, and don't change anything in the core?

[apeisa]

We have mostly disabled sessionFingerprint from whole site. ma 1. huhtik. 2019 klo 13.06 Teppo Koivula <notifications@github.com> kirjoitti:

…

I don't currently work on any ProcessWire client sites, but if my memory serves me right, back in the day we dealt with this issue by always manually disabling the CSRF protection for all new FormBuilder forms, and instructing clients to do the same. When they forgot to do that, submissions would start randomly failing. In the case of FormBuilder I can see two relatively non-obtrusive solutions that would at least improve the situation: - Provide an option in FormBuilder for disabling CSRF protection for new forms by default. - Identify the CSRF setting in FormBuilder when editing a form, and show a warning if CSRF protection is enabled, explaining to the user that this particular combination may be problematic. Obviously that doesn't solve the issue anywhere else. I'm not really sure how to approach this issue in other situations – perhaps leave it to the developer, and don't change anything in the core? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#234 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIDD9beOB4hfgRk7xVVGoA1JO6BeaUAks5vcdoYgaJpZM4M1jfi> .

[tbba]

Same here. We had disabled this feature on every PW website. I would rather have that security feature on in FormBuilder forms but there were to many random problems.

[ryancramerdesign]

@teppokoivula @apeisa @tbba The sessionFingerprint only comes into play once there is an authenticated session (like someone logged into the admin). For regular guest users on the site, the fingerprint is not used.

CSRF used on forms and such is distinct from and not dependent on session fingerprint. A changed fingerprint will not cause CSRF to fail. So for a guest user filling out a form on the site that uses CSRF, there should be no problem if their IP address changes between the time they view the form and they submit the form, and CSRF should continue to function. But if it's a logged-in user and fingerprinting enabled, then fingerprint does come into play — a changed IP address would halt the session before CSRF even was looked at.

As for FormBuilder, there is already a warning about sessionFingerprint and whether or how you may disable it. This appears on on the "Embed" tab, which is what one would need to look at before embedding a form. Again, it only matters for logged-in users. So for most, I think it's best to leave fingerprinting enabled unless your authenticated users are on mobile phones or some other situation where their IPs would be changing often. For most PW installations, the authenticated users are administrators managing content, and for this I think the default fingerprint setting (enabled) is good to have from a security standpoint.

[tbba]

Not sure if this mattes, we switched the feature off, when guest users run into trouble using the form.

[ryancramerdesign]

@tbba The fingerprint feature is already disabled for guest users, so it shouldn't make a difference except for authenticated/logged-in users. Or are you talking about a FormBuilder setting?

[tbba]

This was about Form Builder (this thread started about a Form Builder feature). We were never sure what they did to cause the problem (the clients did not tell)...