What will trigger a CSRF error?

[Robin S]

I have a site where I periodically get CSRF errors when submitting forms in the back-end, logged in as superuser: "This request was aborted because it appears to be forged."

What are the circumstances that will trigger a CSRF error? I know that a change of IP address will, but that won't be happening in this case. Only this one site is affected.

[Robin S]

@adrian, I now think the issue is confined to the Tracy Debugger config page. The site is on a Linode server running PHP 7.0.15 and Ubuntu, yet if I have the "Master" branch selected within the Tracy config every time I submit the config I get a CSRF error. Also, the debug bar does not show in the front-end or back-end on the Master branch. If I temporarily disable CSRF protection, switch to the "Legacy" branch, then re-enable CSRF protection then everything works normally and I can submit the config.

Any ideas what the issue is here? (Feel free to move this to the Tracy support thread if you think it belongs there)

[adrian]

Hi @Robin S - just to clarify - the only "form" this happens on is saving the Tracy settings page?

Are you running the latest version of Tracy?

Do you have the SessionHandlerDB module installed? If so, does it make a difference if you uninstall it?

[Robin S]

I would have said only the Tracy config page (not sure why I didn't make the connection to Tracy straight away) but then I got a CSRF error trying to uninstall SessionHandlerDB also.

So yes, SessionHandlerDB is installed, and uninstalling it does fix the issue.

I am running the latest version of Tracy but the PW version is 2.7.3, and if it matters the SessionHandlerDB module is slightly modified to work around a timezone issue with the module that exists in PW 2.7.

Uninstalling SessionHandlerDB won't be a solution for the production site because the module is used for IP address monitoring by the site owner.

I'm not keen to upgrade the site to PW3 because there's no budget for that, but I can live with the Legacy branch of Tracy as I really only need the bardump feature anyway. What do I miss out on with the legacy branch vs the master branch?

 

[adrian]

Thanks for the extra info.

I have been working to eliminate all the SessionHandlerDB issues - it's been a total PITA. As far as I can tell in PW 3.x the only remaining issue is that the redirect debug bar doesn't show. The normal and AJAX ones work. I haven't tested thoroughly with 2.7 in quite a while. I have been PM'ing with Ryan regarding the redirect bar and it turns out that I do have a solution by modifying Session::redirect (https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/Session.php#L926-L959) to move the header() call to the top of function. Ryan said it used to be that way, but some servers had some issues. I suggested it might be due to the server's "ignore_user_abort" setting, but I am waiting to hear his thoughts on that. 

Sorry, that was probably more detail than you wanted. The upshot though is that I am wondering if that change to Session::redirect might also fix the issue you are having. The other possibility might be this line (https://github.com/adrianbj/TracyDebugger/blob/b3750ee32fd7e5cdf14dc9e58a18ec2ffaab0b01/TracyDebugger.module#L1105) - does removing that help? It's there for other SessionHandlerDB issues, but it can be removed if Session::redirect is modified as mentioned.

Back to the differences between Master (2.4) and Legacy (2.3) of the Tracy core - the primary advantage to Master is the addition of the AJAX bar. You'll actually find the rendering of the debug bar in the Legacy version much faster - I have an issue (https://github.com/nette/tracy/issues/247) posted about this, but not sure much can be done to fix given the way the master version works.

Not sure if that helps or if you feel like investigating any of those tweaks. I don't want to put much more effort into this until I hear back from Ryan because I am already beyond frustrated with the issues with the SessionHandlerDB module, and from what I can tell it is currently pretty good with PW 3.x.

Cheers,
Adrian

[Robin S]

Thanks. Not worth your time to spend ages debugging 2.7.x issues, as just about everyone will be using 3.x going forward. I think perhaps just advise people using 2.7.x together with SessionHandlerDB to run the Legacy branch. Maybe the module could detect those conditions on install and select the Legacy branch by default.

If it's of interest here are a couple of errors I see with Master branch + SessionHandlerDB + PW2.7.3:

PHP Warning: session_regenerate_id(): Cannot regenerate session id - session is not active in /home/mysite/web/test/wire/core/Session.php:459
PHP Warning: Invalid argument supplied for foreach() in .../site/modules/TracyDebugger/TracyDebugger.module:756

 

[adrian]

So I just tested on a PW 2.7 install and I did see your forged error, but it was to do with the Sessions DB table. If you change the "data" field from "text" to "mediumtext", it should fix things. Ryan made that change for me in PW 3 a while ago, but of course it's still an issue with 2.7.

Please let me know if that fixes everything when running the Tracy Master branch.

[adrian]

12 minutes ago, Robin S said:

PHP Warning: Invalid argument supplied for foreach() in .../site/modules/TracyDebugger/TracyDebugger.module:756

I'd like to know more about this one - that is the list of panels to show - would you mind debugging the value of that please - I have never seen an issue there.

Thanks very much!

[Robin S]

Changing the data column type did fix the issue - thanks! I guess that issue occurs because Tracy is storing a lot of data in the session.

Before changing the column type I did some logging of static::$showPanels - much of the time it would be an array but randomly sometimes null.

No more nulls after changing the column type.

 

[adrian]

Awesome @Robin S - thanks for the testing. If I gather correctly, it seems like that column type change has fixed everything which is great. Yes, you are right, Tracy stores the html for all the panels in the session and it can get quite large, especially with all the field object info I have in the PW Info panel.

Glad this was an easy fix in the end

[Robin S]

@adrian, just as an aside: reading the issue you opened on the Tracy GitHub about loading speed there was the suggestion that sessions are the bottleneck. Do you think that having the session data in the DB would speed up that data delivery? In other words, might it improve Tracy performance if both Tracy and SessionHandlerDB are installed?

[adrian]

10 minutes ago, Robin S said:

@adrian, just as an aside: reading the issue you opened on the Tracy GitHub about loading speed there was the suggestion that sessions are the bottleneck. Do you think that having the session data in the DB would speed up that data delivery? In other words, might it improve Tracy performance if both Tracy and SessionHandlerDB are installed?

If anything it appears that SessionHandlerDB makes it worse, at least based on my limited testing.