3.8.x serious security issue with mixing sessions

I don’t think I’ve ever seen this wtih RT, but I have seen it with other
applications - the cause is usually an HTTP proxy that’s caching RT’s
pages. Do you have any sort of HTTP proxy between your browsers and your
server?

No proxy. Also rt is served over https.

There is no proxy but apache serving rt had mod_cache module installed which
turns out to be caching cookies!

Nightmare to track. Uninstalled and so far everything is working nicely.

Now the question is can anything be done on rt level to prevent mod_cache from
cacheing such stuff and actually creating security issues?

Well, what does mod_cache need to know not to cache requests?

I don’t think I’ve ever seen this wtih RT, but I have seen it with
other applications - the cause is usually an HTTP proxy that’s
caching RT’s pages. Do you have any sort of HTTP proxy between your
browsers and your server?

No proxy. Also rt is served over https.

There is no proxy but apache serving rt had mod_cache module installed
which turns out to be caching cookies!

Nightmare to track. Uninstalled and so far everything is working nicely.

Now the question is can anything be done on rt level to prevent mod_cache
from cacheing such stuff and actually creating security issues?

Well, what does mod_cache need to know not to cache requests?

Cache: no-cache but that will prevent caching at all. Seem to be no way to
prevent caching cookies from application side.

Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/

Cache: no-cache but that will prevent caching at all. Seem to be no way to
prevent caching cookies from application side.

What’s the current state of browser in-memory/on-disk caching with the
Cache: no-cache header?

The attached patch against 3.8.6 might be the right solution for you. I’d
consider making this change to RT if you can report back and tell me if
it does the right thing for you:

diff --git a/lib/RT/Interface/Web.pm b/lib/RT/Interface/Web.pm
index b82b638…dccf829 100755
— a/lib/RT/Interface/Web.pm
+++ b/lib/RT/Interface/Web.pm
@@ -279,7 +279,6 @@ sub MaybeShowNoAuthPage {
return unless $m->base_comp->path =~ RT->Config->Get(‘WebNoAuthRegex’);

 # If it's a noauth file, don't ask for auth.
  • SendSessionCookie();
    $m->comp( { base_comp => $m->request_comp }, $m->fetch_next, %$ARGS );
    $m->abort;
    }

Cache: no-cache but that will prevent caching at all. Seem to be no way
to prevent caching cookies from application side.

What’s the current state of browser in-memory/on-disk caching with the
Cache: no-cache header?

The attached patch against 3.8.6 might be the right solution for you. I’d
consider making this change to RT if you can report back and tell me if
it does the right thing for you:

This patch doesn’t solve the issue. People still get mixed sessions (test was
done after deleting all sessions from sessions table and restarting apache).

diff --git a/lib/RT/Interface/Web.pm b/lib/RT/Interface/Web.pm
index b82b638…dccf829 100755
— a/lib/RT/Interface/Web.pm
+++ b/lib/RT/Interface/Web.pm
@@ -279,7 +279,6 @@ sub MaybeShowNoAuthPage {
return unless $m->base_comp->path =~
RT->Config->Get(‘WebNoAuthRegex’);

 # If it's a noauth file, don't ask for auth.
  • SendSessionCookie();
    $m->comp( { base_comp => $m->request_comp }, $m->fetch_next, %$ARGS );
    $m->abort;
    }

Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/

This patch doesn’t solve the issue. People still get mixed sessions (test was
done after deleting all sessions from sessions table and restarting apache).

Hang on. is mod_cache caching more than the files marked “static, never
changes”? Since this patch should stop RT from putting cookie headers on
any static content (and a fair bit more taht we can get away without
them on)

-j

I just found this thread about Mixed sessions. We are experiencing the
same problem with RT 3.8.7, sitting behind an Apache based proxy +
load balancer. The backend is a MySQL cluster but that should not have
an impact on the user sessions.

We have two instances of RT connected to the same backend. In other
words, the front ends connect (load balance) to two RTs. These RTs
connect to the same Cluster.

Could the apache load balancer be the issue?

Suggestions?
Thierry