CSRF and Apache Configuration conflicts.

[objecttothis]

Issue / Question / Bug

Before submitting an issue please make sure you tick (add an x between the square brackets with no spaces) the following check boxes:

• I'm reporting an issue of an unmodified OSPOS installation
• I checked open and closed issues database and no similar issue was already discussed (please make sure you searched!)
• I read the README, WHATS_NEW and UPGRADE
• I read the FAQ (https://github.com/jekkos/opensourcepos#faq) for any known install and/or upgrade gotchas (in specific PHP has php-gd, php-intl, sockets and etc. installed)
• I read the wiki
• I ran any database upgrade scripts (e.g. database/2.4_to_3.0.sql), and migrating function
• I'm aware the latest master could be a development version and therefore not stable
• I know the version of OSPOS and git commit hash (check the footer of your OSPOS), the name and version of OS, Web server, PHP and MySQL and will add them to my issue report

Installation information

• OSPOS version is: 3.1.0
• OSPOS git commit hash is:
• PHP version is: (e.g. 5.5, 5.6, 7.0, 7.1) 5.6.31
• MySQL or MariaDB version is: (e.g. MySQL 5.5, MySQL 5.6, MySQL 5.7, MariaDB 10.0, MariaDB 10.1, MariaDB 10.2) 5.7
• OS and version is: (e.g. CentOS 6.9, Ubuntu 16.4, Windows 10) FreeBSD 11.0
• WebServer is: (e.g. Apache 2.2, Apache 2.4, Nginx 1.12, Nginx 1.13) Apache 2.4
• (If applicable) Installation package for the LAMP/LEMP stack is: (e.g. WAMP, XAMPP) FAMP

Expected behaviour

This issue was originally referenced in #1488 but since that is about a different problem, I thought i'd create a new issue in case anyone else runs into the problem.

With CSRF enabled (by default) be able to login to app.

Actual behaviour

I get an error telling me "The action you requested is not allowed" upon submitting my username and password. In, my case this is caused by the line Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure in my Apache httpd.conf file which, curiously is to prevent XSS attacks (https://geekflare.com/httponly-secure-cookie-apache/) but it appears that because it alters the cookie, CSRF in codeigniter kicks in and blocks the login.

The solution is to comment out that line in httpd.conf if you have access to it. There may also be a way to correct it in .htaccess files, but I haven't looked into it.

Steps to reproduce the issue

I've already resolved the issue, but I'm posting it in case anyone else runs into the issue.

[jekkos]

Hmm might be better to add this to the FAQ (Readme.md) or wiki, as we always refer to those in case 'common' problems occur. But I must admit that this is the first bug report on this one..

Adding httpOnly prevents javascript from reading out the cookie value. This will probably break some of the CSRF injection that's done in ajax form submit situations. I tihnk the CI choice of adding CSRF token to the cookie is not the best one as now we fail to deploy a XSS hardening measure. The better choice would have been adding a separate header for the CSRF token.

[objecttothis]

Yeah, I opened an issue on their github asking about it.

[objecttothis]

So I thought my issues with CSRF were limited to the login, but I'm finding that it's also blocking saving data in the app config. When CSRF is turned off it works fine, but when it's enabled it fails. I'm going to try to compare configurations with my shared hosting web server and the hardened server to see if I can figure out why CodeIgniter CSRF is being triggered even with that line commented out of my httpd.conf. I have mod_security in DetectionOnly and Suhosin in simulation mode. I've already commented out my open_basedir and disable_functions in php.ini but it still persists. I might go over to the CI forums and see if I can find anyone with similar issues in their server config.

[objecttothis]

FINALLY! If php.ini contains suhosin.cookie.encrypt = On then CSRF will fail. There are two ways to resolve this. Either comment that line out (unsafe) or add the line suhosin.cookie.plainlist = csrf_cookie_ospos_v3 (safe)

This should be added to a FAQ, wiki or troubleshooting guide as anyone with suhosin running is liable to run into this and suhosin.simulation = On does not make the problem go away and suhosin doesn't log it because it's not technically suhosin blocking anything which makes the problem difficult to track down.

This issue can be closed once we figure out the best place to document the issue for future people.

[daN4cat]

Added to FAQ and committed to master. This can be closed now.

[jekkos]

Ok great, thanks for sorting this out!