for what I recall, I just hit the save button. I never saw it for a help page…sorry
Maybe it wasn’t you but your user agent sent that request. The log file states it!
I want to investigate “background” requests…
35 seconds before the line in logs with the 400 answer…the log states the error at [18/Apr/2018:18:21:52 +0200]
Could you attach more lines towards the past?
last time it happened on my machine I was on the users tab updating the domain admins account.
Could you attach the previous ~20 lines?
192.168.1.10 - - [17/Apr/2018:21:14:24 +0100] "GET /en-US/Resource/d13ef2c8.js HTTP/1.1" 200 81781 192.168.1.10 - - [17/Apr/2018:21:14:33 +0100] "GET /en-US/MailAccount/Userfirstname.lastname@example.org?_=1523996064382 HTTP/1.1" 200 2434 192.168.1.10 - - [17/Apr/2018:21:14:48 +0100] "GET /en-US/MailAccount/SharedMailbox/delete/testsharedmail.json?_=1523996064383 HTTP/1.1" 200 1387 192.168.1.10 - - [17/Apr/2018:21:14:50 +0100] "POST /en-US/MailAccount/SharedMailbox/delete/testsharedmail.json HTTP/1.1" 200 1032 192.168.1.10 - - [17/Apr/2018:21:15:23 +0100] "GET /en-US/MailAccount/Useremail@example.com?_=1523996064384 HTTP/1.1" 200 2432 192.168.1.10 - - [17/Apr/2018:21:15:27 +0100] "GET /en-US/Applications HTTP/1.1" 200 10764 192.168.1.10 - - [17/Apr/2018:21:15:27 +0100] "GET /en-US/Resource/3597b6c5.js HTTP/1.1" 200 48197 192.168.1.10 - - [17/Apr/2018:21:15:31 +0100] "GET /en-US/Dashboard HTTP/1.1" 200 17060 192.168.1.10 - - [17/Apr/2018:21:15:31 +0100] "GET /en-US/Resource/d457179b.css HTTP/1.1" 200 1982 192.168.1.10 - - [17/Apr/2018:21:15:31 +0100] "GET /en-US/Resource/0617d151.js HTTP/1.1" 200 53629 192.168.1.10 - - [17/Apr/2018:21:15:31 +0100] "GET /en-US/AdminTodo.json?notifications&_=1523996131710 HTTP/1.1" 200 360 192.168.1.10 - - [17/Apr/2018:21:15:45 +0100] "GET /en-US/Sssd HTTP/1.1" 200 14044 192.168.1.10 - - [17/Apr/2018:21:15:46 +0100] "GET /en-US/Resource/561d1927.css HTTP/1.1" 200 376 192.168.1.10 - - [17/Apr/2018:21:15:46 +0100] "GET /en-US/Resource/390b5a7b.js HTTP/1.1" 200 50463 192.168.1.10 - - [17/Apr/2018:21:16:46 +0100] "GET /en-US/Account HTTP/1.1" 200 36540 192.168.1.10 - - [17/Apr/2018:21:16:46 +0100] "GET /en-US/Resource/b6e1ddfa.css HTTP/1.1" 200 762 192.168.1.10 - - [17/Apr/2018:21:16:46 +0100] "GET /en-US/Resource/953b0494.js HTTP/1.1" 200 75076 192.168.1.10 - - [17/Apr/2018:21:17:11 +0100] "GET /en-US/Account/Groupfirstname.lastname@example.org?_=1523996206819 HTTP/1.1" 200 923 192.168.1.10 - - [17/Apr/2018:21:17:14 +0100] "POST /en-US/Account/Groupemail@example.com HTTP/1.1" 200 1287 192.168.1.10 - - [17/Apr/2018:21:17:19 +0100] "GET /en-US/Account/Groupfirstname.lastname@example.org?_=1523996206820 HTTP/1.1" 200 910 192.168.1.10 - - [17/Apr/2018:21:17:30 +0100] "GET /en-US/Help/Read/Account.html HTTP/1.1" 200 4314 192.168.1.10 - - [17/Apr/2018:21:20:06 +0100] "POST /en-US/Account/Groupemail@example.com HTTP/1.1" 400 59
Thank you very much @bobtskutter, it confirms my hypotesis: the bug originates (at least) from the Help button.
I’ve had the error message come up a few times and I’ve been a regular user of the help button, so that seems to make sense.
Another replication pattern is the following:
- open two browser tabs for the same session, 1 then 2
- go back to tab 1 and push a red submit button
This is the issue with the proposed solution
new package available from nethserver-testing /cc @quality_team.
Please check it out!
yum install http://packages.nethserver.org/nethserver/7.4.1708/testing/x86_64/Packages/nethserver-httpd-admin-2.1.1-1.4.g8c4b72b.ns7.noarch.rpm
Any chance to see it ported to 6.x? I may create patches and PR. Should I request it here?https://github.com/NethServer/nethgui/tree/v6
Yes I think the commits can be cherry-picked and backported to ns6. But it could be quite complex, because there are multiple issues to backport:
I’m preparing an RPM, would you mind testing it?
I think this backport should be part of NethServer 6.10 /cc @dev_team
Why not. I will test on 6.9, if possible.
You can install the packages with
yum localinstall http://packages.nethserver.org/nethserver/6.10/testing/x86_64/Packages/nethserver-base-2.11.3-1.1.g0309248.ns6.noarch.rpm http://packages.nethserver.org/nethserver/6.10/testing/x86_64/Packages/nethserver-httpd-admin-1.6.8-1.1.ge02348c.ns6.noarch.rpm
More info available here: http://dev.nethserver.org/issues/3445
I can confirm the bug at 6.9 with stable updates as today (2018-07-19). The bug is easily reproducible with the second set of instructions (using multiple tabs; obviously no Account Provider tab is available on 6.x).
Once installed the proposed packages, I tried to reproduce the bug but I cannot. I modified several different things on different tabs, opening also help pages, the issue didn’t arise once. Full log of the httpd-admin sessions (before and after the manual upgrade) here.
I recently developed the webgui for this additional package and it showed the 400 Error for the CSRF after visiting the Help page. After the updates, the bug is gone.
Expiration rules verified after 5 actions as requested.
I cannot update the Enhancement #3445, as I have an account for dev but never been able to post anything on it.
Thank you for the detailed report, Emiliano!
I’ll switch the issue state to “verified” on the old issue tracker for you.
I think I’ll release the fix for 6.9 too, by disabling the session lifetime check for backward compatibility. Session expiry will be enabled by default on new 6.10 installs. What do you think?
Good news to me . Session lifetime seems to be really “safe” from the user POV anyways (1 hour on idle and 8 hours of total lifetime is a quite permissive approach to session expiration, IMHO), but I understand the point.
A wise choice, as always. I think 5 actions per session may be a little low (think about adding many NATs or firewall rules/objects, which you may choose to open in two different tabs for simplicity); a configurable threshold may be much more fitted IMHO (you can raise it if it bothers you when you are administering stuff, then bring it back to the default at the end of the task in case), but once you know the security issue and why it was implemented so you can surely bare with it anyways.
Thanks for your involvement and support, much appreciated as usual.
Just to clarify, the limit of 5 refers to simultaneously opened pages. Each time a full HTML page is requested a new CSRF token is generated. The session records the last 5 tokens so that any AJAX request containing one of them can be validated.
When you work on the same HTML page the token does not change.