Keep getting "CSRF detected!"

[RobA]

Using an anatomizing proxy like TOR will also trigger the CSRF detection.

-Rob A>

[SamWM]

Same reason as mine - IP address changing between requests

[yojoe]

I've seen somewhere that this problem might be caused by a script looping login method multiple times.
On some webservers starting multiple sessions within fixed time may lead to csrf(xss) attack, thus some cms-es disallow multiple tab/window login, and automatically logouts user or ends his sessions.

Carlos found somewhere a similar loop causeing afair sitemap to be generated couple times before saving.

[SamWM]

What fixes it for me is changing

Code:

$ip = $_SERVER['REMOTE_ADDR'];

to

Code:

$ip = ""; // or a random string, as long as it doesn't change between requests

in the get_nonce function in the file admin\inc\security_functions.php. If IP address changes, the nonce changes, <?php echo $_SERVER['REMOTE_ADDR'] ?> confirmed it for me. The hash is already salted, so is IP address needed?

[Ampersand]

I have been experiencing CSRF for a few days recently. Some info on background situation:

• I have several sites on GS 2.03 and 3.0, from which some share identical password and/or login
  
• to one of them I have recently added:
  

Code:

ExpiresActive On
<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|swf)$">
ExpiresDefault A2592000
</FilesMatch>

to .htaccess, which I rely on.

As impulse solutions I tried the following, from which some worked:

• logged out, but afterwards admin/index.php redirected me automatically to admin/pages.php - in other words I couldn't log in properly until I deleted manually login cookie
  
• turned off browser-cache (via WebDeveloper of Firefox) - worked once
  
• logged in, saved a page, logged out - all with Google Chrome, which I have edited just this one site once - this worked and CSRF did not reappear in Firefox for a few days when I logged in, out and saved normally
  
• logged in, saved a page, logged out - again with Google Chrome - this worked and CSRF did not reappear in Firefox for one login, some saves and a logout only - form next login CSRF was back.
  

I have purposefully pointed out this different scenarios and may be irrelevant info as can't see any consistency in browser behaviour - except for Chrome seems immune for CSRF in my case. I suspect it may be related to files handling by browser or server, but really have no idea. Hope someone sorts it out one day.

As a permament solution I launched into space line 36 of changedata.php and sleep sound.

[Connie]

Hallo Ampersand,

I am glad that GS 3.1 has the option to set off this "nonce - nonsense":

Code:

# Turn off CSRF protection. Uncomment this if you keep receiving the error message "CSRF error detected..."
define('GSNOCSRF', TRUE);

I asked some collegues in the meantime, nobody had any idea what the reason could be unfortunately

[Ampersand]

Tweaking edit.php that I mentioned in a post above was good till the moment I wanted to update css file of the theme of one of my 2.03 installs. In this case theme-edit.php comes into action so it would require a similiar tweak as edit.php. Instead of tweaking it I decided to observe the beast in the wild and made minor changes to both theme-edit.php and nonce.php to compare the variables compared in nonce.php. These variables must have been different to cause CSRF alert.
So I changed line 44 of theme-edit.php to

Code:

print("inner nonce=".$nonce);    if(!check_nonce($nonce, "save"))

and line 41 of nonce.php to

Code:

print("<br/>outer hash=".get_nonce($action, $file)."<br/>");    return ( $nonce === get_nonce($action, $file) );

Then I proceeded to the test:
-started Firefox
-logged in
-edited css theme file and saved it
-received:

Code:

inner nonce=5beb6ceea80bc2d3eef440e4f14b0db2753ccda3
outer hash=462faccca9b2d0f835db060a8964219a43399eb8
CSRF detected!

I wanted to check why is the $nonce passed from theme-edit.php different than the produced within nonce.php, but beforehand... as you can see form previous post: Google Chrome worked fine.
So I checked the same steps with Chrome:
-logged out
-started Chrome
-logged in
-edited css theme file and saved it
-received:

Code:

inner nonce=973d74b22c7dc7b07de581e9be2a30011d110502
outer hash=973d74b22c7dc7b07de581e9be2a30011d110502

identical as mono-zygotic twins this time.

Definitely not a cross-browser solution...

Ok, now back to firefox: why were nonces-schmonzes different in FF? This time no sha1 in line 28 of nonce.php (don't replicate without parental guidance!):

Code:

$hash=$action.$file.$ip.$USR.$SALT;

Firefox:

Code:

inner nonce=save/admin/theme-edit.php188.146.124.177Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz
outer hash=save/admin/theme-edit.php178.180.225.246Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz

Chrome:

Code:

inner nonce=save/admin/theme-edit.php188.147.29.93Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz
outer hash=save/admin/theme-edit.php188.147.29.93Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz

wow, what a miraculous browser...
Will IPs remain identical in FF?

firefox:

Code:

inner nonce=save/admin/theme-edit.php188.147.29.93Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz
outer hash=save/admin/theme-edit.php188.147.29.93Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz

Yes, as I wrote previously - once or twice a single use of Chrome removed CSRF for some time in FF, so above you can see why.

But, will IPs remain identical in FF from now on? That's what happened after a couple of minutes:
firefox:

Code:

inner nonce=save/admin/theme-edit.php188.146.57.204Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz
outer hash=save/admin/theme-edit.php178.180.109.170Redakcjav4pwwe37necqoo1z1b0^1durtz4dh-unx1bz

Sad... I am sorry my provider does it to IP, but does he do it really? Or may be some browsers change HTTP headers? So now I use solution from SamWM's post: change line 25 of nonce.php (remember my example is from 2.03) to
$ip = $_SERVER['REMOTE_ADDR'];$ip=true;

[shawn_a]

I have to turn off modsec to avoid this with my host.
Of course I only turn it off for my IP, and if a post.
Luckily my host allows this override.

Code:

.htaccess

SetEnvIf Remote_Addr ^xxx\.xxx\.xxx\.xxx$ MODSEC_ENABLE=Off
SetEnvIf Request_Method !^POST$ MODSEC_ENABLE=On

*ip masked

[bugmenot]

I have this issue as well. And I just found out that i can disable this. But is my page now insecure? I guess yes.

I am devellopping my site on local server and on my host. I often get it when i copy pages (xml files) from my localhost to my server and then try to edit them. I althaugt had problems when renaming/deleting tempates. I could not edit the pages (withotu the CRSF error sometime i think) somehow i edited the pages to the existing template and uploaded them and then it workend. I thaught i got the error reason. But looks like i did not.

Are this only login checks or could it have something to do with the files?

[Connie]

I have this issue as well. And I just found out that i can disable this. But is my page now insecure? I guess yes.

No. This is just one step. It is not the complete protection.
And this "security"-feature is a very exotic one, all the other stable sites demonstrate that it is not necessary

The only security it gave me was that I could not publish. ;=(

[rfuller]

For those here that are not coders a couple of pages that helped me understand a little about CSRF.

CSRF = Cross-Site Request Forgery for those that may know what it is.

http://blog.preinheimer.com/index.php?/a...ction.html

http://en.wikipedia.org/wiki/Csrf

Bob