Kombinierte Ansicht Flache Ansicht Baumansicht
Threads [ Zurück | Nächste ]
toggle
Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 27. August 2009 09:13
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 27. August 2009 09:20
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 27. August 2009 09:59
RE: Liferay Security Vulnerability: Session Hi-Jacking Aritz Galdos 27. August 2009 23:56
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 1. September 2009 11:52
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 5. Oktober 2009 09:41
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 5. Oktober 2009 11:59
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 6. Oktober 2009 09:34
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 6. Oktober 2009 09:50
RE: Liferay Security Vulnerability: Session Hi-Jacking Mika Koivisto 6. Oktober 2009 10:27
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 14. Oktober 2009 12:53
RE: Liferay Security Vulnerability: Session Hi-Jacking Olaf Kock 6. Oktober 2009 11:42
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 6. Oktober 2009 13:09
RE: Liferay Security Vulnerability: Session Hi-Jacking Olaf Kock 6. Oktober 2009 11:35
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 19. Oktober 2009 14:15
RE: Liferay Security Vulnerability: Session Hi-Jacking Michael Poznecki 14. Dezember 2009 11:49
RE: Liferay Security Vulnerability: Session Hi-Jacking Krati Gupta 27. Juli 2010 02:10
RE: Liferay Security Vulnerability: Session Hi-Jacking Johan de jong 16. Oktober 2012 03:17
RE: Liferay Security Vulnerability: Session Hi-Jacking Mika Koivisto 16. Oktober 2012 12:04
RE: Liferay Security Vulnerability: Session Hi-Jacking Luiz Henrique Grossl 18. Januar 2013 09:15
Fuad Efendi
Liferay Security Vulnerability: Session Hi-Jacking
27. August 2009 09:13
Antwort

Fuad Efendi

Rang: Regular Member

Nachrichten: 148

Eintrittsdatum: 5. April 2007

Neue Beiträge

Hello,

I am constantly having problems with user sessions, accidentally User may get access to a session of another User (for instance, he will see message "Welcome, User2" instead of "Welcome, User1")

How this happens and why?

Half a year ago I noticed related post Apache HTTPD but is was for old version; we are using 2.2

Tomcat also has some bugs (fixed) like as
- Tomcat incorrectly treated a single quote character (') in a cookie value as a delimiter. In some circumstances this lead to the leaking of information such as session ID to an attacker.

- Tomcat incorrectly handled the character sequence \" in a cookie value. In some circumstances this lead to the leaking of information such as session ID to an attacker.


Do you guys have ever had such kind of problems? Do you run specific load-stress tests to ensure that this does not happen with Apache?

Thanks
casaGURU Renovation Professionals
Online Shopping
Liferay Consultant
Lisa Simpson
RE: Liferay Security Vulnerability: Session Hi-Jacking
27. August 2009 09:20
Antwort

Lisa Simpson

Rang: Liferay Legend

Nachrichten: 2034

Eintrittsdatum: 5. März 2009

Neue Beiträge

We've not seen this behaviour with Liferay 5.2.3 or the EE. However, we're running tomcat 6. The whole thing, however, is frontended by Apache running mod-proxy which gives me the ability to filter out a lot of stuff.

RegEx is the bomb... if something matches X (nasty part of string) it gets routed into the bit bucket.

HTH
Fuad Efendi
RE: Liferay Security Vulnerability: Session Hi-Jacking
27. August 2009 09:59
Antwort

Fuad Efendi

Rang: Regular Member

Nachrichten: 148

Eintrittsdatum: 5. April 2007

Neue Beiträge

Yes, we need to upgrade to latest versions... still 5.12 on tomcat 5.5.26... I noticed some posts at RedHat too, in some cases suggested
org.apache.tomcat.util.http.ServerCookie.VERSION_SWITCH=true
- but I am verifying it now...

I use mog_proxy_ajp; HTTPD 2.2

May be this???
http://issues.liferay.com/browse/LEP-7061

- sometimes HTTPD restart helps, but not now...
Aritz Galdos
RE: Liferay Security Vulnerability: Session Hi-Jacking
27. August 2009 23:56
Antwort

Aritz Galdos

Rang: Expert

Nachrichten: 397

Eintrittsdatum: 15. Mai 2007

Neue Beiträge

Hi

I never had this problem but something similar happen when you log to the portal with different users from the same webBrowser.

i.e. When I log to the portal from two different navigator instances everi thing is ok. But if I log to the portal with two different users in the same browser, (I mean same browser, different tabs) both user convert in the last logged user. I think
Lisa Simpson
RE: Liferay Security Vulnerability: Session Hi-Jacking
1. September 2009 11:52
Antwort

Lisa Simpson

Rang: Liferay Legend

Nachrichten: 2034

Eintrittsdatum: 5. März 2009

Neue Beiträge

If you try to open to two tabs in the same browser as different users, you can't. It will merge them into the last user to authenticate successfully. That appears to be the default behavior as of 5.2.3. That particular behavior, as far as I can tell, is actually cookie based, not session based. One of the devs can feel free to correct me if I'm mistaken. I've not dug into it that deeply.

In this case, we're actually talking about a third party maliciously assuming your session to, for example, replace your web content with spam or pr0n. That's a bit trickier.
Fuad Efendi
RE: Liferay Security Vulnerability: Session Hi-Jacking
5. Oktober 2009 09:41
Antwort

Fuad Efendi

Rang: Regular Member

Nachrichten: 148

Eintrittsdatum: 5. April 2007

Neue Beiträge

The problem is not "two tabs in the same browser as different users" - it is much more serious!!!

It happens in moderately loaded production system with Apache HTTPD 2.2 (worker) on front end, when we have more than a few concurrent users from different geo-locations.

It happens mostly with PortletSession stored objects, but sometimes it even happens with "Welcome, John Smith" message - it shows name of another user, Session Hi-Jacking - a user gets access to a Session of another one.

Tomcat has resolved many related bugs with specific characters in a Session ID - what about Liferay, is it generating own non-compatible Session IDs?
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5333
Apache Tomcat 6.0.0 through 6.0.14, 5.5.0 through 5.5.25, and 4.1.0 through 4.1.36 does not properly handle (1) double quote (") characters or (2) %5C (encoded backslash) sequences in a cookie value, which might cause sensitive information such as session IDs to be leaked to remote attackers and enable session hijacking attacks.

I don't think it happens with HttpSession.

Many years ago I had similar problem - but it was FTP - and I suspected Firewall/Router/NIC suddenly mixing TCP sessions...

It is extremely difficult to locate a problem without specific LAB environment (which SUN-Liferay must have!)
Lisa Simpson
RE: Liferay Security Vulnerability: Session Hi-Jacking
5. Oktober 2009 11:59
Antwort

Lisa Simpson

Rang: Liferay Legend

Nachrichten: 2034

Eintrittsdatum: 5. März 2009

Neue Beiträge

If it is indeed cookie based, it shouldn't be your network gear causing the problem *UNLESS* your network gear is caching the cookie and handing out the same cookie to several users. I can say that we've not seen that here at all. We've got 18K users. The worst thing I've seen is the tab thing. The session ID's that I've seen are all totally alphanumeric.

Your apache2.2, are you running mod_jk or mod_proxy?
Fuad Efendi
RE: Liferay Security Vulnerability: Session Hi-Jacking
6. Oktober 2009 09:34
Antwort

Fuad Efendi

Rang: Regular Member

Nachrichten: 148

Eintrittsdatum: 5. April 2007

Neue Beiträge

And of course cookie is passed via HTTP header:

1. Fixed in Apache httpd 2.2.12
important: mod_proxy_ajp information disclosure CVE-2009-1191
An information disclosure flaw was found in mod_proxy_ajp in version 2.2.11 only. In certain situations, if a user sent a carefully crafted HTTP request, the server could return a response intended for another user.


2. Fixed in Apache httpd 2.2.6
moderate: mod_cache information leak CVE-2007-1862
The recall_headers function in mod_mem_cache in Apache 2.2.4 did not properly copy all levels of header data, which can cause Apache to return HTTP headers containing previously used data, which could be used by remote attackers to obtain potentially sensitive information.

Update Released: 7th September 2007

Affects: 2.2.4



And, of course, our famous vendor RedHat ENTERPRISE(???) still provide us with HTTPD v.2.3.3 (as of October-2009)

(we are using mod_mem_cache)
Lisa Simpson
RE: Liferay Security Vulnerability: Session Hi-Jacking
6. Oktober 2009 09:50
Antwort

Lisa Simpson

Rang: Liferay Legend

Nachrichten: 2034

Eintrittsdatum: 5. März 2009

Neue Beiträge

Yet another reason we use Ubuntu's Long Term Support Server for most of our *nix boxes. In spite of the fact that it's a free download, their package managers are pretty responsive in pushing out security patches.
Mika Koivisto
RE: Liferay Security Vulnerability: Session Hi-Jacking
6. Oktober 2009 10:27
Antwort

Mika Koivisto

LIFERAY STAFF

Rang: Liferay Legend

Nachrichten: 1498

Eintrittsdatum: 7. August 2006

Neue Beiträge

The source of your problems is probably mod_mem_cache. You can easily configure it to cache liferay pages so that other users get the cached version from someone else thus appearing to have hi-jacked the session accidentally. I've seen this happen with overly aggressive proxy servers.
Olaf Kock
RE: Liferay Security Vulnerability: Session Hi-Jacking
6. Oktober 2009 11:35
Antwort

Olaf Kock

LIFERAY STAFF

Rang: Liferay Legend

Nachrichten: 1828

Eintrittsdatum: 23. September 2008

Neue Beiträge

Lisa Simpson:
If you try to open to two tabs in the same browser as different users, you can't. It will merge them into the last user to authenticate successfully. That appears to be the default behavior as of 5.2.3.


That's actually not default behaviour in Liferay, but behaviour of the browser. As the browser in this case sends the same cookie (with the session identifier) to the server from each tab, naturally the same session is running in the same tab, with the same user (and only that one user) being logged in.

With cookies that's as far as you get unless you get specific support from the browsers so that they send different session cookies from different tabs.
Olaf Kock
RE: Liferay Security Vulnerability: Session Hi-Jacking
6. Oktober 2009 11:42
Antwort

Olaf Kock

LIFERAY STAFF

Rang: Liferay Legend

Nachrichten: 1828

Eintrittsdatum: 23. September 2008

Neue Beiträge

keep in mind that usually distributions don't update you to the latest version of a product, but backport security relevant fixes to their version of choice. This is expected behaviour in Enterprise distributions. You wouldn't want them to always install the latest feature with each security update, requiring you to lock down these new features with every security update. And there's no such thing as a gentoo enterprise edition (no pun intended, but they have the habit and reputation to always run the latest versions of everything and use a significant fraction of the CPU to steadily compile and optimize the heck out of the system ;-)

As you mention mem_cache: I was about to suggest taking a close look to your infrastructure to any proxy and caching stuff going on there. As you seem to be more or less alone with the problems you describe, chances are that it's your infrastructure, not liferay. What you mentioned really sounded more like caching going wrong than "specially crafted headers".

If you need more aggressive caching for performance reasons you might want to look into integrating a cdn for serving static resources (thus keeping it out of tomcat's/liferay's realm) or cluster your installation to span multiple hosts.
Lisa Simpson
RE: Liferay Security Vulnerability: Session Hi-Jacking
6. Oktober 2009 13:09
Antwort

Lisa Simpson

Rang: Liferay Legend

Nachrichten: 2034

Eintrittsdatum: 5. März 2009

Neue Beiträge

Don't even get me started on Gentoo.... Is it uberfast? Yes, but any time my servers save, I spend managing their patching process. IMHO, their packaging is inconsistent at best. Who releases an apache update without mod_auth???

Mod_disk_cache and other apache cacheing mods are known to cause this sort of inadvertent session-hijacking.
Fuad Efendi
RE: Liferay Security Vulnerability: Session Hi-Jacking
14. Oktober 2009 12:53
Antwort

Fuad Efendi

Rang: Regular Member

Nachrichten: 148

Eintrittsdatum: 5. April 2007

Neue Beiträge

Mika Koivisto:
The source of your problems is probably mod_mem_cache. You can easily configure it to cache liferay pages so that other users get the cached version from someone else thus appearing to have hi-jacked the session accidentally. I've seen this happen with overly aggressive proxy servers.



The problem is HTTP Headers.

I disabled mod_mem_cache, but it still happens. Should I disable mod_proxy_ajp too?!

I'll upgrade HTTPD...

BTW, Liferay manages what is cached and what not; via HTTP headers such as "Last Modified Time", "ETag", "Expire:", and etc. - at least, should. And in case of cached Image, for instance, HTTP response shouldn't include session cookie.

Difficult to locate the problem; it could be even broken router/firewall.
Fuad Efendi
RE: Liferay Security Vulnerability: Session Hi-Jacking
19. Oktober 2009 14:15
Antwort

Fuad Efendi

Rang: Regular Member

Nachrichten: 148

Eintrittsdatum: 5. April 2007

Neue Beiträge

http://httpd.apache.org/docs/2.2/mod/mod_cache.html

CacheIgnoreHeaders Set-Cookie


Ok, I played with this setting, Mozilla Firefox + Live Http Headers plugin. I tried to find objects which use HTTP Caching and Set Cookie, and I found single one:


GET /html/js/barebone_packed.js?bn=5102 HTTP/1.1
Host: www.casaguru.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 GTB5 (.NET CLR 3.5.30729)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.casaguru.com/home
Cookie: LOGIN=7765626d617374657240746f6b656e697a65722e6f7267; SCREEN_NAME=5a72696354705a66776846326a346e774774743731773d3d; __utma=47926453.1823828619112278800.1242160515.1255467895.1255557828.210; __utmz=47926453.1247854694.124.6.utmcsr=public.casaguru.com|utmccn=(referral)|utmcmd=referral|utmcct=/professional; GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true; _csuid=49146af247b1ff77; REMEMBER_ME=true; COMPANY_ID=10097; ID=7553696a623545574e59513d; PASSWORD=536e31726637374a474e6b3d; __utmc=47926453; JSESSIONID=85B6F7297C58438BDA17FF189483C316; __utmb=47926453.2.10.1255557828
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Date: Wed, 14 Oct 2009 22:16:48 GMT
Set-Cookie: JSESSIONID=F830DD5D4F0ED8F595F4343DCA576FD6; Path=/
Expires: Fri, 16 Oct 2009 22:16:49 GMT
Cache-Control: max-age=172801, public
Etag: W/"176773-1234388745000"

Content-Encoding: gzip
Content-Length: 48814
Last-Modified: Wed, 11 Feb 2009 21:45:45 GMT
Connection: close
Content-Type: text/javascript



After setting "CacheIgnoreHeaders Set-Cookie" problem disappears... BTW, I checked all images/CSS/JavaScript, only barebone_packed tries to set cookie together with caching - why?

===============

Please note:
1. GET /html/js/barebone_packed.js?bn=5102 HTTP/1.1

2. It is cached content:
Expires: Fri, 16 Oct 2009 22:16:49 GMT
Cache-Control: max-age=172801, public
Etag: W/"176773-1234388745000"

3. Cookie is provided:
Set-Cookie: JSESSIONID=F830DD5D4F0ED8F595F4343DCA576FD6;


Now, it seems we don't have any problem anymore, after CacheIgnoreHeaders Set-Cookie

However, HTTPD may respond with non-cached content in case (for instance) of cache limits / expirations; what about people behind corporate proxies/caches? We can't manage external caching servers...

It is a bug.
Michael Poznecki
RE: Liferay Security Vulnerability: Session Hi-Jacking
14. Dezember 2009 11:49
Antwort

Michael Poznecki

Rang: Expert

Nachrichten: 301

Eintrittsdatum: 10. Dezember 2008

Neue Beiträge

I'm having a similar problem.
Krati Gupta
RE: Liferay Security Vulnerability: Session Hi-Jacking
27. Juli 2010 02:10
Antwort

Krati Gupta

Rang: Regular Member

Nachrichten: 113

Eintrittsdatum: 5. Dezember 2008

Neue Beiträge

I am also facing the same problem , can anybody tell how to fix the issue .
Johan de jong
RE: Liferay Security Vulnerability: Session Hi-Jacking
16. Oktober 2012 03:17
Antwort

Johan de jong

Rang: Junior Member

Nachrichten: 35

Eintrittsdatum: 6. Februar 2012

Neue Beiträge

Sorry that i reopen an old list, but i have the exact problem at this moment with
Liferay Portal Community Edition 6.1.0 CE (Paton / Build 6100 / January 6, 2012)
running at Glassfish 3.1.1

A company who has a proxyserver has several users who want to login to the liferay server. At some moments they login and they get the message that they are logged in as an other user.

How can i resolve this nightmare?
Mika Koivisto
RE: Liferay Security Vulnerability: Session Hi-Jacking
16. Oktober 2012 12:04
Antwort

Mika Koivisto

LIFERAY STAFF

Rang: Liferay Legend

Nachrichten: 1498

Eintrittsdatum: 7. August 2006

Neue Beiträge

You can stop caching in the proxy server or you can upgrade. If I remember correctly the issue is fully resolved in 6.1 GA2.
Luiz Henrique Grossl
RE: Liferay Security Vulnerability: Session Hi-Jacking
18. Januar 2013 09:15
Antwort

Luiz Henrique Grossl

Rang: New Member

Nachrichten: 1

Eintrittsdatum: 24. August 2010

Neue Beiträge

Mika Koivisto:
You can stop caching in the proxy server or you can upgrade. If I remember correctly the issue is fully resolved in 6.1 GA2.


We couldn't upgrade yet our Liferay 6 to 6.1 so we've added:

1<IfModule mod_headers.c>
2  ## used to avoid Liferay 6 User session hijack problem
3  Header merge Cache-Control no-cache
4  Header merge Cache-Control no-store
5  Header merge Cache-Control private
6</IfModule>


to our Apache front-end servers to stop the problem for now.

Keep in mind that Liferay pages will be served a little bit slower because of the no-cache, we are thinking about adding the static content into Apache to speed up things again.