Nethserver Update Fails with Server error Nethgui: 400 - Bad Request

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…

1 Like

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?

1 Like
1 Like

last time it happened on my machine I was on the users tab updating the domain admins account.

httpd-admin/access-log
image

httpd-admin/error-log

1 Like

Could you attach the previous ~20 lines?

@davidep

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/User/update/admin@xxxxxxxx.org.uk.json?_=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/User/update/dave@xxxxxxxx.org.uk.json?_=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/Group/delete/dandc@xxxxxxxx.org.uk.json?_=1523996206819 HTTP/1.1" 200 923
 192.168.1.10 - - [17/Apr/2018:21:17:14 +0100] "POST /en-US/Account/Group/delete/dandc@xxxxxxxx.org.uk.json HTTP/1.1" 200 1287
 192.168.1.10 - - [17/Apr/2018:21:17:19 +0100] "GET /en-US/Account/Group/update/domain%20admins@xxxxxxxx.org.uk.json?_=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/Group/update/domain%20admins@xxxxxxxx.org.uk.json HTTP/1.1" 400 59
1 Like

Thank you very much @bobtskutter, it confirms my hypotesis: the bug originates (at least) from the Help button.

1 Like

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.

1 Like

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
1 Like

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

Thanks, regards,

1 Like

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.

Thanks, regards,

2 Likes

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 :+1: . 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.

1 Like