Did I cause any security issues to my site in solving my login issue of "This request was aborted because it appears to be forged" ?

[Violet]

My question relates to one of my live sites. I empirically managed to solve my login issue of "This request was aborted because it appears to be forged" [details below], but I don't understand the inner workings of PW, so I don't understand the theory behind why/how I fixed it, and thus, I don't know if I've managed to inadvertently introduce a security issue/loophole.

Would anyone please be willing to let me know if my change, moving forward, is likely to cause any such issues? I don't have any reason to believe I *do* have a security issue (I made my change only an hour ago) but I am hoping other users can weigh in on this.

DETAILS:

The problem:

Yesterday I updated 2 of my sites from 3.0.165 to 3.0.184 from within PW admin page, using the upgrade module - this is the way I've always done it. Immediately afterword, both sites appeared to be working fine from front-end and admin, and I even wrote and saved an (unpublished) article in what would become the problem site, then I logged out. Unfortunately, this morning, although both sites were fine from front-end, I could not log into the admin area of the problem site, getting "This request was aborted because it appears to be forged". The other site was fine and I could log into that.

The solution:

Since both my sites were on the same web host and had a lot of similarities, this was actually incredibly helpful as it let me narrow down where the issue might be. I won't go into everything that *didn't* work (although I noted it all down at the time so I have it if anyone asks for it), EXCEPT for 1 thing that might turn out to be relevant: the "good" site had site/config.php  perms of 0644, and the "problem" site had perms of 0400. I tried changing the problem site perms to 0644 but that didn't fix the issue, so then I changed it to 0600 so I could at least write to it (e.g. to change $debug to true, etc).

By comparing the contents of the 2 site/config.php files, I was able to narrow down the difference (this was AFTER ruling out a bunch of other things that I won't go into here). The difference is that the problem site had these extra lines which were absent in the good site:

 $config->sessionAllow = function($session) {
 
    // if there is a session cookie, a session is likely already in use so keep it going
    if($session->hasCookie()) return true;
 
    // if URL is an admin URL, allow session
    if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true;
 
    // otherwise disallow session
    return false;
  };

I commented out those lines and afterwards everything worked and I could log back into the admin area of the problem site. So, problem fixed, yay!! But - WHY were those lines there in the first place? They must have been from an older version of PW that I was running in the past. So they must have been doing SOMETHING, so have I caused a security issue in deleting them? Any advice you have about that would be very helpful.

And also, was it therefore a bad idea to have my site/config.php perms on 0400? They're on 0600 right now on that site in case future PW upgrades need to change config.php. I thought 0400 was 'good' based on https://processwire.com/docs/security/file-permissions/#potential-permissions-for-site-config.php but perhaps I should have done 0600.

Thank you for reading this and for any insight you can provide.

[Clarity]

Hello, @Violet!

It also sometimes happens with me while I'm trying to log in or save the page. Usually reloading the page with clearing cache helps me to avoid this problem. But not sure how to fix it so that it won't appear in the future.

[horst]

On 9/2/2021 at 5:42 PM, Violet said:

 $config->sessionAllow = function($session) {
 
    // if there is a session cookie, a session is likely already in use so keep it going
    if($session->hasCookie()) return true;
 
    // if URL is an admin URL, allow session
    if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true;
 
    // otherwise disallow session
    return false;
  };

This can be used to avoid sessions on the front end, or on some pages. (And allow them for the admin, where it is needed)

You should check this site in regard of its GDPR rules / announcements. (In regard that you not now has enabled sessions where it should not be.)

 

On 9/2/2021 at 5:42 PM, Violet said:

was it therefore a bad idea to have my site/config.php perms on 0400? They're on 0600 right now on that site in case future PW upgrades need to change config.php

0400 is better == more secure. If you need to update the site/config.php in the future, you THEN can set it temporary to 0600 for your changes, and directly afterwards back to 0400.