roundcube / roundcubemail

The Roundcube Webmail suite
https://roundcube.net
GNU General Public License v3.0
5.89k stars 1.64k forks source link

CSRF message when tab reloading tab #5776

Closed cellsheet closed 7 years ago

cellsheet commented 7 years ago

Hello, I have an issue with the CSRF mechanism implemented in roundcube. After I login and I close the tab with roundcube if I didn't logout, and re-open the tab, I get the message regarding the CSRF warning.

I could think of a million reasons why someone didn't logout before closing the tab (persistent login plugin, restarting chrome, rebooting without closing chrome, power outage, etc). I do not for this reason it is practical to assume the user can successfully close their session in the same time they opened it without these things occurring sometimes.

Is there a way to disable this or at least move it into config.php, or even make this a plugin? I believe this should be left up to the user if they want to enable it due to the aforementioned reasons. I cannot imagine what would happen to gmail if no-one could suddenly re-access email if everyone just forgot to log out.

EDIT: Deleting line https://github.com/roundcube/roundcubemail/blob/master/index.php#L252 fixes it, however I would like to see this addressed regarding these scenario's.

alecpl commented 7 years ago

What version? Looks like you're using use_secure_url=true, right? Then there should be a link below the warning, clicking it should open the requested page.

This is CSRF protection, user has to "confirm" he's not a (hacker) robot. I don't see how that could be improved.

cellsheet commented 7 years ago

For me it shows "Please contact your server administrator", no link to resume your session. I also had that disabled, which I think I'll be enabling. That could have been possibly the issue? Roundcube 1.2.5 complete. I should have suspected this as a bug, my bad.

EDIT: Enabling that option didn't fix, still seeing "Please contact your server-administrator."

alecpl commented 7 years ago

How exactly do you "re-open the tab"? What URL are you using?

cellsheet commented 7 years ago

Essentially I just opened a new tab, copy/pasted the roundcube root folder where I login to, and it displays the message. That or just simply deleting ?_task=mail&_mbox=INBOX off the URL when I am logged in, then loading that. Basically it prevents me having more than one tab with my inbox or anything open at any given time, or just going back to it if I close the tab and try to go back to it.

alecpl commented 7 years ago

I'm not able to reproduce.

cellsheet commented 7 years ago

I don't know if I cleared everything, but even after wiping the whole roundcube install, and dropping the database, it still persisted. I'm just unsure if I left anything out though..

EDIT: use_secure_urls = true will trigger the CSRF dialog with the option to resume my session upon logout, however it 404's when I click that. I noticed this requires a RewriteRule, however I'm using nginx. What would I put in my defaults server block to get the equivalent rules?

EDIT 2: rewrite "^/roundcubemail/[a-f0-9]{16}/(.*)" /roundcubemail/$1; is what came from a generator, will update if this works.

EDIT 3: This did not seem to fix the issue. :(

alecpl commented 7 years ago

I believe you. There's indeed a code that displays the warning without the link. It's used in rare cases (but valid imo) However, I can't reproduce it with the steps you describe. Maybe be more precise. So, what browser, what URLs (precisely, what was the url before you closed the tab and what is the URL of the new tab, do you close the browser or only the tab), what timings (you do this immediately or wait some time), where you click and what you press?

cellsheet commented 7 years ago

I believe it started happening after I installed a few plugins, notably the google authenticator 2fa, and persistent login. However, since then I wiped the directory and then I was able to still reproduce this on first use. I also did delete from session in the roundcube table before clearing the cache as well as cookies for the login portal and hard reloading it. I'm using chrome and chromium, both at latest revisions on arch linux, and I close just the tabs after doing this then re-navigating to the page, and I do all these in succession immediately. I have since then however installed libpam-google-authenticator (the issue happened before this was installed) as well as freeradius (this is set as sufficient because it's not completely configured right now), so I'm working on re-working the pam modules such that roundcube doesn't rely on it, only sshd. I can attempt to dig deeper giving the headers and such if that does not seem to lead anywhere when I get the chance to again.

alecpl commented 7 years ago

According to https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roundcube/rcube.php#L972 there are two possibilities:

So, how precisely do you re-navigate to the page?

cellsheet commented 7 years ago

I will either delete every part of the url except the part for the root of the roundcube install part, so like in my case, I have it in the mail folder in /home/www/mail, and I will go to https://example.com/mail to login. So while a session is active, I will delete everything from the url to match https://example.com/mail, and press enter to load it. That or just ctrl+n for new tab, and load https://example.com/mail. With that being said, I can check my headers too once I get another unrelated issue resolved if needed against those conditions. Will update this actually when I get a chance to check the headers and such.

EDIT: When I open a new tab, here are the details. One thing I also noticed is that in my nginx site block to enable use_secure_urls=true, I included this as it was generated from the Apache RewriteRule that was given. However, the CSRF message still appears whether this is enabled or not

        location / {
                rewrite "^/mail/[a-f0-9]{16}/(.*)" /mail/$1;
        }

Just for reference, here is the url that is loaded upon login: https://example.com/mail/?_task=mail&_mbox=INBOX

Request headers:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:roundcube_sessid=<string>
roundcube_sessauth=<string>
DNT:1
Host:example.com
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Here are the response headers:

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 31 May 2017 12:10:38 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Expires: Wed, 31 May 2017 12:10:38 GMT
Last-Modified: Wed, 31 May 2017 12:10:38 GMT
Cache-Control: private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-DNS-Prefetch-Control: off
X-Frame-Options: sameorigin
Content-Language: en
Content-Encoding: gzip
Request Headers
view source

Also, this is what I get when I login when it is valid. The roundcube_sessid and roundcube_sessauth seem to match between the original login POST and the login GET from trying to re-open the mail page at https://example.com/mail where it gives me the CSRF message.

Request headers:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:137
Content-Type:application/x-www-form-urlencoded
Cookie:roundcube_sessid=6q20f88lq2t1prq8s3ihbif875
DNT:1
Host:cellsheet.info
Origin:https://example.com
Referer:https://example.com/mail/
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Response headers:

Cache-Control:private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection:keep-alive
Content-Type:text/html; charset=UTF-8
Date:Wed, 31 May 2017 12:13:53 GMT
Expires:Wed, 31 May 2017 12:13:53 GMT
Last-Modified:Wed, 31 May 2017 12:13:53 GMT
Location:./?_task=mail&_token=<string>
Pragma:no-cache
Server:nginx
Set-Cookie:roundcube_sessauth=-del-; expires=Wed, 31-May-2017 12:12:53 GMT; Max-Age=-60; path=/; secure; httponly
Set-Cookie:roundcube_sessid=<string>; path=/; secure; HttpOnly
Set-Cookie:roundcube_sessauth=<string>; path=/; secure; httponly
Transfer-Encoding:chunked
X-DNS-Prefetch-Control:off
X-Frame-Options:sameorigin

Query string parameters: _task=login

Form data:

_token:<string>
_task:login
_action:login
_timezone:America/New_York
_url:
_user:username
_pass:password

Replacing with the appropriate tokens/id's/sessions.

alecpl commented 7 years ago

Not sure it's the problem here, but your rewrite regexp is wrong (old). For version >=1.2 it should be rewrite "^/mail/[a-zA-Z0-9]{16}/(.*)" /mail/$1;. But you don't use use_secure_urls=true, right?

I see no roundcube_sessauth cookie in the second request headers you provided.

cellsheet commented 7 years ago

That would be correct, I have the feature set to false because of bad re-writes from the regex. I'll try the one you provided and update.

alecpl commented 7 years ago

No feedback.

ajuanjojjj commented 2 years ago

Happened to me today; navigating to the inbox via the left menu fixed it. Using chrome 96.0.4664.110 and Roundcube Webmail 1.4.11 via Plesk, and Apache 2.4.41 and Nginx 1.20.1. It did not have the resume sesion link, rather "Please contact your administrator". Happy to provide more info (assuming i'm able to get it)