CSRF check failed on login

[ThomasKorimort]

Hello!

I had a working installtion of nextcloud 12 running on my Raspbian stretch up-to-date Raspberry Pi 3 home server. Because of some issues with external storage and apache 2 shutting down often i upgraded to nextcloud 13. However, i got strange issues at login, why i changed to owncloud. I was happy to find a Debian package for stretch. After installing that via the repository i followed all the steps for installing php extensions, restarting apache and so on. I made a new database in Mariadb. I changed the file permissions to www-data:www-data for using the setup web interface. I also prepared the site-configuration file for owncloud exactly as in the instruction. However, before i had a different one. After successful (????) setup i tried to login via the web interface from my desktop machine's web browser to my server, but i got an error:

Access denied. CSRF check failed. This much happens. From little bit research in the internet there were old contributions relating such errors to PHP problems, but till some days ago my nextcloud 12 was working nicely with my up-to-date Raspbian 9 Stretch system. I think the issue is related to both nextcloud and owncloud, which have both released new versions recently.

[dmitry]

Hi,

maybe this could be helpful to you:

Issue: CSRF check failed

You could also just disable the CSRF check in your config.php.

'csrf.disabled' => true,'

[ThomasKorimort]

Thanks for the info... In how far is the CSRF check essential to the security of the cloud?

[ThomasKorimort]

Hi! After switching off csrf check, i can login as administrator, but at the file screen get the message that owncloud cannot load the page. This seems to be a bug. Maybe as long as there is no files that error message is displayed. That is the same message i got after updating to from Nextcloud 12 to Nextcloud 13. Now, the same error appears also for the most recent version of Owncloud 10. I ran the script provided on https://doc.owncloud.org/server/10.0/admin_manual/installation/installation_wizard.html#post-installation-steps for setting file permissions in post-installation procedure.

[dmitry]

I would try to set the permissions manually, to exclude an error in the script or if it's not suitable for your setup.

I have also found something in our doc

https://doc.owncloud.com/server/10.0/admin_manual/installation/configuration_notes_and_tips.html?highlight=csrf#session-auto-start-enable-post-data-reading

[tom42]

Maybe its really also just an issue on your setup if both (ownCloud and Nextcloud) are showing the same behavior? I think the link posted by @dmitry above (https://github.com/owncloud/core/issues/25927#issuecomment-262703655) shows that there are quite a lot misconfigurations on server side known to cause such a CSRF check failed message.

It seems in a few additional comments further issues could be found:

browser cache related (https://github.com/owncloud/core/issues/25927#issuecomment-271838460)

cookies disabled in browser (https://github.com/owncloud/core/issues/25927#issuecomment-333084040)

lacking disc space (https://github.com/owncloud/core/issues/25927#issuecomment-277237545)

webserver messing with cookies (https://github.com/owncloud/core/issues/25927#issuecomment-356147763)

tempdir issue (https://github.com/owncloud/core/issues/25927#issuecomment-334137448)

php session folder issue (https://github.com/owncloud/core/issues/25927#issuecomment-330965669)

[ThomasKorimort]

Post_Max_Size was set in my PHP 7.0 configuration to 8M. I changed to 512M and it did not solve my problem. session.auto.start setting was by default correct. enable post data reading setting was also correct by default. I am using Raspbian 9 Stretch on Rasberry Pi 3. PHP session file seems also to be correct by default. Only if i swith off CSFR check, then i can login and even after that things seem not to work completely correctly...

[tom42]

then i can login and even after that things seem not to work completely correctly...

Maybe there is something else broken and the CSRF message is just a side-effect of this? It could be possible that inspecting your logfiles of e.g. webserver, php or owncloud gives you some hints.

I think another possibility could be to setup a fresh OS like e.g. Debian Stretch in a VM, install ownCloud there and then compare the setup like e.g. PHP Configuration, Permissions etc. of that working System with your current one.

[ThomasKorimort]

Hi! I looked in the log file of owncloud after disabling CSRF check. There was an error because the themes folder was not there. I installed the directory tree from debian package from the owncloud site. Same happens for the tarball. The themes directory is missing and is producing an error message. After again enabling the CSRF check, in the owncloud logfile it is just mentioned that the login failed without further specification.

[cdamken]

I had a working installtion of nextcloud 12 running o

Hi, I think you are looking for another forum. this is ownCloud central, you are using the wrong software. please go to their forum.

[tom42]

Hi, I think you are looking for another forum. this is ownCloud central, you are using the wrong software. please go to their forum.

From what i understand the same happens on a ownCloud installation of the user as well so i think the forums here is fitting as well.

[ThomasKorimort]

the thing with the themes folder seems to also popup in the nextcloud as well owncloud installation according to manuals for nextcloud 13 and owncloud 10. They seem to have pretty much the same code base???? This issue can be corrected easily by making a themes folder with proper access rights and maybe putting some of the contents in that the owncloud installation is searching for after the login. The CSRF thing maybe one can simply switch off and forget about it. I don't know. As far as i know one can buy professionally packed NAS drives with owncloud on them easily in electronic markets. Maybe such installations would work nicely. However, there was also a lot of fuzz about making an owncloud/nextcloud server on a Raspberry Pi, which is essentially my use case. If that would really work nicely (and my nextcloud 12 was working somehow although in several aspects unsatisfactory), one would have the constellation of running an own cloud at the cost of a Raspberry Pi 3 (ca. 80-90 EURO including accessories), electricity cost of 20 EURO for running the server day and night a whole year. Using a dynamic DNS provider and forwarding the proper port of the web server to the Raspberry Pi. That is a total amount of cost equal to peanuts everyone could afford. The only pity is that ISPs charge money for fixed IPs and for your right to drive your own DNS server (who provides domain registration with free and unrestricted access to the DNS record of your domain?). Theoretically ICANN allows someone who is certified by ICANN to provide domain registration also free of charge, but currently ICANN has only comissioners for country level top level domains and extraordinary domains, but not for free and unrestricted domains. It would be so nice to have a .linux or .opensource or .freesociety unrestricted and free of charge top level domain.

[tom42]

I don't have a theme folder in my ownCloud 10.0.7 installation folder and not getting any errors. Maybe you're running an outdated version of ownCloud?

[ThomasKorimort]

I used the most recent Debian package and later tarball. Since it is a PHP project is suspect it should not matter, whether i run it on a Raspberry Pi 3 with an up-to-date Raspbian Stretch or on any other machine. And nextcloud 12 used to work, though the web server was deactivating itself regularly, which was annoying and i did not solve that isseu before i changed to owncloud 10.0.7. And as mentioned before the only error messages in the owncloud.log was the failed login when CSRF is activated and the missing themes folder, otherwise the logfile was pretty empty.

[cdamken]

They seem to have pretty much the same code base????

No, is not the same.

Did you install a fresh installation from ownCloud, including Database or just tried to migrate the software?

[ThomasKorimort]

I deleted the old database as i did not fill it extensively under Nextcloud 12. I also deleted the nextcloud folder and made a completely new owncloud folder from the Debian package of owncloud 10.0.7. From that i got the error messages as listed above (missing themes folder, login failed). The missing themes folder message was only displayed after i deactivated the CSRF check according to the hint of 'dmitry' in the config.php file of my owncloud installation. Those two messages were the only ones in my error log. Also after login (having CSRF check deactivated) immediatley the next error message is displayed on the webpage "Problem beim Laden der Seite" (problem while loading the page) which might be due to the missing themes folder...

[cdamken]

The theme folder is not necessary for version 10, you can have it as app, but you have first to check in your config.php if you have the entry, if that is, remove it or create a theme folder to avoid the error.

It would help more if you put the log files and your config.php (remove the passwords) , then we can see the stack trace and analyze the code better.

[cdamken]

I've seen in https://github.com/owncloud/core/pull/29950 that since 10.0.5 you should be directed to the login page if your CSRF fails. Probably your configuration from Apache has a missing configuration. Can you provide that too?

[ThomasKorimort]

Hi! I did yesterday some update of my Debian packages in which i had included the Debian repository for owncloud files. I noticed that the package seemed to be 10.0.5 and was updated to 10.0.7. Still, after update the error remains: "Problem while loading the page. Page will be loaded in 5 seconds." German original: "Problem beim Laden der Seite. Seite wird in 5 Sekunden geladen." That happens directly after login provided CSRF is switched off.

The apache2.conf looks like this on my owncloud Raspberry Pi 3 server:

This is the main Apache server configuration file. It contains the

configuration directives that give the server its instructions.

See http://httpd.apache.org/docs/2.4/ for detailed information about

the directives and /usr/share/doc/apache2/README.Debian about Debian specific

hints.

Summary of how the Apache 2 configuration works in Debian:

The Apache 2 web server configuration in Debian is quite different to

upstream's suggested way to configure the web server. This is because Debian's

default Apache2 installation attempts to make adding and removing modules,

virtual hosts, and extra configuration directives as flexible as possible, in

order to make automating the changes and administering the server as easy as

possible.

It is split into several files forming the configuration hierarchy outlined

below, all located in the /etc/apache2/ directory:

/etc/apache2/

|-- apache2.conf

| `-- ports.conf

|-- mods-enabled

| |-- *.load

| `-- *.conf

|-- conf-enabled

| `-- *.conf

`-- sites-enabled

`-- *.conf

* apache2.conf is the main configuration file (this file). It puts the pieces

together by including all remaining configuration files when starting up the

web server.

* ports.conf is always included from the main configuration file. It is

supposed to determine listening ports for incoming connections which can be

customized anytime.

* Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/

directories contain particular configuration snippets which manage modules,

global configuration fragments, or virtual host configurations,

respectively.

They are activated by symlinking available configuration files from their

respective *-available/ counterparts. These should be managed by using our

helpers a2enmod/a2dismod, a2ensite/a2dissite and a2enconf/a2disconf. See

their respective man pages for detailed information.

* The binary is called apache2. Due to the use of environment variables, in

the default configuration, apache2 needs to be started/stopped with

/etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not

work with the default configuration.

Global configuration

ServerRoot: The top of the directory tree under which the server's

configuration, error, and log files are kept.

NOTE! If you intend to place this on an NFS (or otherwise network)

mounted filesystem then please read the Mutex documentation (available

at );

you will save yourself a lot of trouble.

Do NOT add a slash at the end of the directory path.

ServerRoot "/etc/apache2"

The accept serialization lock file MUST BE STORED ON A LOCAL DISK.

Mutex file:${APACHE_LOCK_DIR} default

The directory where shm and other runtime files will be stored.

DefaultRuntimeDir ${APACHE_RUN_DIR}

PidFile: The file in which the server should record its process

identification number when it starts.

This needs to be set in /etc/apache2/envvars

PidFile ${APACHE_PID_FILE}

Timeout: The number of seconds before receives and sends time out.

Timeout 300

KeepAlive: Whether or not to allow persistent connections (more than

one request per connection). Set to "Off" to deactivate.

KeepAlive On

MaxKeepAliveRequests: The maximum number of requests to allow

during a persistent connection. Set to 0 to allow an unlimited amount.

We recommend you leave this number high, for maximum performance.

MaxKeepAliveRequests 100

KeepAliveTimeout: Number of seconds to wait for the next request from the

same client on the same connection.

KeepAliveTimeout 5

These need to be set in /etc/apache2/envvars

HostnameLookups: Log the names of clients or just their IP addresses

e.g., www.apache.org (on) or 204.62.129.132 (off).

The default is off because it'd be overall better for the net if people

had to knowingly turn this feature on, since enabling it means that

each client request will result in AT LEAST one lookup request to the

nameserver.

HostnameLookups Off

ErrorLog: The location of the error log file.

If you do not specify an ErrorLog directive within a

container, error messages relating to that virtual host will be

logged here. If you do define an error logfile for a

container, that host's errors will be logged there and not here.

ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel: Control the severity of messages logged to the error_log.

Available values: trace8, ..., trace1, debug, info, notice, warn,

error, crit, alert, emerg.

It is also possible to configure the log level for particular modules, e.g.

"LogLevel info ssl:warn"

LogLevel warn

Include module configuration:

Include list of ports to listen on

Sets the default security model of the Apache2 HTTPD server. It does

not allow access to the root filesystem outside of /usr/share and /var/www.

The former is used by web applications packaged in Debian,

the latter may be used for local directories served by the web server. If

your system is serving content from a sub-directory in /srv you must allow

access here, or in any related virtual host.

AllowOverride None
Require all granted

Options Indexes FollowSymLinks
AllowOverride None
Require all granted

Options Indexes FollowSymLinks

AllowOverride None

Require all granted

AccessFileName: The name of the file to look for in each directory

for additional configuration directives. See also the AllowOverride

directive.

AccessFileName .htaccess

The following lines prevent .htaccess and .htpasswd files from being

viewed by Web clients.

The following directives define some format nicknames for use with

a CustomLog directive.

These deviate from the Common Log Format definitions in that they use %O

(the actual bytes sent including headers) instead of %b (the size of the

requested file), because the latter makes it impossible to detect partial

requests.

Note that the use of %{X-Forwarded-For}i instead of %h is not recommended.

Use mod_remoteip instead.

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined

Include of directories ignores editors' and dpkg's backup files,

see README.Debian for details.

Include generic snippets of statements

Include the virtual host configurations:

vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Then there are also several files in conf-enabled, especially 2 seem related to php: phpmyadmin standard apache configuration:

phpMyAdmin default Apache configuration

Alias /phpmyadmin /usr/share/phpmyadmin

Options SymLinksIfOwnerMatch
DirectoryIndex index.php

<IfModule mod_php5.c>
    <IfModule mod_mime.c>
        AddType application/x-httpd-php .php
    </IfModule>
    <FilesMatch ".+\.php$">
        SetHandler application/x-httpd-php
    </FilesMatch>

    php_value include_path .
    php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp
    php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/
    php_admin_value mbstring.func_overload 0
</IfModule>
<IfModule mod_php.c>
    <IfModule mod_mime.c>
        AddType application/x-httpd-php .php
    </IfModule>
    <FilesMatch ".+\.php$">
        SetHandler application/x-httpd-php
    </FilesMatch>

    php_value include_path .
    php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp
    php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/
    php_admin_value mbstring.func_overload 0
</IfModule>

Authorize for setup

Disallow web access to directories that don't need it

and php7.0-fpm.conf:

Redirect to local php-fpm if mod_php is not available

# Enable http authorization headers

SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1

<FilesMatch ".+\.ph(p[3457]?|t|tml)$">
    SetHandler "proxy:unix:/run/php/php7.0-fpm.sock|fcgi://localhost"
</FilesMatch>
<FilesMatch ".+\.phps$">
    # Deny access to raw php sources by default
    # To re-enable it's recommended to enable access to the files
    # only in specific virtual host or directory
    Require all denied
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(p[3457]?|t|tml|ps)$">
    Require all denied
</FilesMatch>

Otherwise some other files are present in the conf-enabled folder: javascript-common.conf ...

[tom42]

Maybe you can try to switch from php-fpm to mod_php?