"CSRF verification failed. Request aborted."

[AlexF]

Hello FreeNAS gurus,
I performed GUI upgrade to 9.3.0 from 9.2.1.7 without realising that my USB boot disk is only 4GB. The upgrade failed. I replaced USB disk with 16GB and loaded 9.3.0 ISO and then via (http) GUI, I loaded my backed-up configuration (.db) file.
I can login via SSH access and I can see my filesystem via SAMBA.

The problem is that I am now getting
Forbidden (403)
CSRF verification failed. Request aborted.
More information is available with DEBUG=True."
error attempting to login via (http) GUI.

Can I please ask kind soul for assistance - how to login?
R's, Alex

 

[sysfu]

This problem came back for me too after upgrading to the FreeNAS 9.3 release. It only happens with Opera 12x though, not Chrome or IE. Trying a different browser is the easiest workaround. You can see my Opera fix here

 

[AlexF]

> It only happens with Opera 12x though, not Chrome or IE

this happens to me using IE, Firefox and Chrome.

It seems like 9.3.0 bug. Any workaround, I don't want to downgrade after all this?

 

[sysfu]

I'm not 100% sure it's a 9.3 bug because I can log into a FreeNAS 9.3 release system with all the latest updates using both Comodo Dragon (equiv of Chrome 36.1) and Internet Explorer. Opera 12.14 x64 is still giving me problems but I run a pretty paranoid browser security setup.

Do you have SSH access to the system? Updates can be applied from the command line like so:

freenas-update -C /var/db/system/update check; freenas-update -C /var/db/system/update update; reboot

 

[AlexF]

> Updates can be applied from the command line like so:

Thanks, I did, but I'm still getting "Forbidden (403)" "CSRF verification failed. Request aborted.".

I'm quite sure it's not the 3 browsers at fault. Besides, same GUI access worked to allow me initial access in order to loaded my 9.2.1.7 backed-up configuration (.db) file. So, it's something in 9.2.1.7 configuration migration that is causing this error in 9.3.0.

Also, I know 100% that in 9.2.1.7, I used HTTPS to access GUI but migration to 9.3.0 has only opened up HTTP. (This also means that this has nothing to do with Certificates since SSL/TLS's not involved.)

 

[Sinjiku]

Hello

I have the same problem. I did exactly like AlexF in his first post.
I can add Safari 8.0.1 to the browser list with the CSRF bug :)

 

[Prasanth]

Add me to the list of users with this problem. In fact it happened when I updtaed in the same exact way. I first installed full version then did an update via web gui.

 

[sysfu]

Related bug reports:
https://bugs.freenas.org/issues/7049
https://bugs.freenas.org/issues/5595
https://bugs.freenas.org/issues/6351

 

[AlexF]

Related bug reports:
https://bugs.freenas.org/issues/7049

This looks like a candidate.

 

[Prasanth]

Anyone try the patch and instructions? Did that work?

 

[Prasanth]

Tried the patch out with same resulting error.

 

[Lorsung23647]

Same error with Chrome and IE 11 on Windows 8.1

 

[Jon Radel]

If you're talking about the instructions and patch in bug #7049, they fixed the problem for me once I corrected the instructions. The patch was fine.

1. Revert your patched config upload by executing a factory restore form the GUI---> System--->Factory Restore.

2. SSH into your freenas box, copy the patch included in this post to /etc/local/rc.d and from the same directory execute the below:
patch -p1 < django.patch

3. Restart Django for the settings to take effect:
patch -p1 < django.patch

4. Upload original unaltered config from 9.1.1 (or whatever) and see the results.
​

Step 1 seems rather cruel given that the whole issue is that there is no GUI. I ignored it.
Step 2 worked fine
Step 3 is wrong. Try something more along the lines of
./django restart
while still in the /etc/local/rc.d directory
Step 4 was not necessary for me given that step 1 was impossible.

That recipe left me with a GUI running in HTTP only despite the old config I had uploaded earlier calling for HTTPS only (with warning that it had fallen back to using HTTP given lack of valid cert). I then uploaded a cert that it approved of and specified that cert in the GUI setup, rolled my eyes at where it redirected me after I hit Save, and found that all was well after I specified the correct HTTPS URL and attached again.

I'm not sure that I think all this breakage just because I was using a free CAcert certificate for my internal access only NAS box was a good idea -- I can see warnings about certs that aren't from a CA in the approved list, but blowing it off entirely? Plenty of people use internal CAs, or something like CAcert, for internal access only equipment. Luckily I had a "real" wildcard cert available from dealing with something else.

 

[Lorsung23647]

Those instructions fixed it for me as well. Kind of wish that I didn't have to buy an ssl cert now, but I guess it happens.

 

[Jon Radel]

Those instructions fixed it for me as well. Kind of wish that I didn't have to buy an ssl cert now, but I guess it happens.

I had an existing wildcard cert which suited the FreeNAS box's name, so I went with the "real" option. It looks like they've added all sorts of options for generating certs with an internal CA, etc., which should suit to both keep FreeNAS happy and remain free. Given that I had a cert in hand, I didn't research that option further. See http://doc.freenas.org/9.3/freenas_system.html#cas for lots more. (And I must say that I find the notion that the security officer who runs the enterprise CA would be willing to give the key for same to random person running random NAS is rather bizarre, so I may be missing the entire point.

 

[Sinjiku]

Great !

Thanks, doing that fix it.

:)

 

[Lorsung23647]

I had an existing wildcard cert which suited the FreeNAS box's name, so I went with the "real" option. It looks like they've added all sorts of options for generating certs with an internal CA, etc., which should suit to both keep FreeNAS happy and remain free. Given that I had a cert in hand, I didn't research that option further. See http://doc.freenas.org/9.3/freenas_system.html#cas for lots more. (And I must say that I find the notion that the security officer who runs the enterprise CA would be willing to give the key for same to random person running random NAS is rather bizarre, so I may be missing the entire point. :)

I did follow the instructions for generating a self signed cert from Freenas, but I then receive an invalid cert message from every browser, and only Firefox will bypass it.

 

[Keek]

If you're talking about the instructions and patch in bug #7049, they fixed the problem for me once I corrected the instructions. The patch was fine.

The patch in connection with your instructions solved the problem for me as well, Thx!

 

[AlexF]

The patch is changing following line in /etc/local/rc.d/django
from:
if [ ${webguiproto} = "https" ]; then
to:
if [ ${webguiproto} = "https" -a ! -f /tmp/alert_invalid_ssl_nginx ]; then

Once modified and django restarted using "./django restart" (needing twice for some reason) I could login using HTTP.

As per 5.9. CAs, I created internal CA (System->CA) and then internal Certificate (System->Certificates) referencing forementioned internal CA; then changed Protocol to HTTPS (System ->General : Protocol) and rebooted.

Now can login using HTTPS. (Browser will complain because certificates is signed by non-trusted CA - you'll need to tell it to create an exception).

 

[Lorsung23647]

Something must have gone wrong when I setup my cert last time. I just recreated my internal one, and everything's fine now.