CSRF constantly triggering on login
-
Any ideas what might be causing this, or if there is a way to disable the check?
I always manually logout at end of a session, Next time I login I have to go through an extended process to get to the dashboard (it used to be less in your face on older builds).
Browser is Vivaldi.
-
Most common way I've seen that happen is if you click the login button multiple times, like a double click/tap.
-
@chrcoluk I have this issue with Vivaldi as well. Doesn't happen in incognito mode apparently for me.
@jimp I've been able to reproduce this on a VM install of pfsense, and an install on a physical machine. Both were version 2.4.5-RELEASE-p1.
I just spun up a test VM, and through initial config it was fine. Then the CSRF started triggering, before I've even made any changes.
-
I ran into this sort of behavior when setting up an SG-2100 the other day and thought of this post. When I pulled up the login page on my iPhone it was, I'm assuming, using a cached version, as the initial login attempt would always fail. I found if I always reload the page before logging in it was fine. This was even if I had logged out, closed the "tab"/page in Safari, closed Safari, etc.
-
@teamits said in CSRF constantly triggering on login:
I ran into this sort of behavior when setting up an SG-2100 the other day and thought of this post. When I pulled up the login page on my iPhone it was, I'm assuming, using a cached version, as the initial login attempt would always fail. I found if I always reload the page before logging in it was fine. This was even if I had logged out, closed the "tab"/page in Safari, closed Safari, etc.
Hm interesting. Let me give this a shot and see in a little bit.
You're seeing this in safari? Any other browsers?
I meant to test all browsers on my computer and see what happens and post, but haven't gotten to it yet. -
@noncarbonatedclack I was in Safari on my phone at the time. On my PC it's easily duplicated in Firefox by logging out and leaving the tab open to the login page for a few hours...which means it is therefore a correct message, that the token expired.
The page headers show "cache-control: no-store, no-cache, must-revalidate" but maybe iOS Safari doesn't follow that? I didn't look into it much except for noting the reload "fixed" it.
-
Like in the other thread, one cause of the problem has been determined to be when the page is idle for too long.
Auto refresh might feel a bit of a scuffed solution, so a more elegant solution would be after e.g. 1 hour (depends on the token expiry), then it will auto load a holding page once instead of auto refresh, which you first have to click before seeing the login page, then you have a fresh token and no CSRF issue.
-
If the browser or a password manager aggressively caches the form against all directives from the firewall, what do you expect the firewall to do?
The firewall is stopping the clients from acting in an insecure manner, which is the best thing for a firewall to do.
Maybe we can find some tricky way around it without reducing security, but clearly the problem here is squarely on the client(s) not behaving properly.
-
I was using Firefox Lockwise on my iPhone. To my knowledge it doesn't store anything besides login/password...?
Something else I've noticed that is odd. With Lockwise, if I get to the red CSRF screen (https://forum.netgate.com/topic/152075/missing-or-expired-csrf-token) and tap the Back button in Safari, I end up at the dashboard (i.e. I don't have to accept the error, or log in again).
And note it isn't an issue in Firefox for Windows, which is the same password list.
I'm not trying to insist it's a pfSense issue, just weird behavior.
-
To follow up on my post, I eventually realized that the Lockwise on my phone was auto-submitting the form when credentials were picked (unlike the Firefox web browser). However with a slight delay on the page load I didn't notice that and submitted the form myself (again). That explains all my symptoms.
