Fóruns

Início » Liferay Portal » English » 2. Using Liferay » General

Visualização combinada Visão plana Exibição em árvore
Tópicos [ Anterior | Próximo ]
toggle
Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 27 de Agosto de 2009 09:13
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 27 de Agosto de 2009 09:20
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 27 de Agosto de 2009 09:59
RE: Liferay Security Vulnerability: Session Hi-Jacking Aritz Galdos 27 de Agosto de 2009 23:56
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 1 de Setembro de 2009 11:52
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 5 de Outubro de 2009 09:41
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 5 de Outubro de 2009 11:59
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 6 de Outubro de 2009 09:34
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 6 de Outubro de 2009 09:50
RE: Liferay Security Vulnerability: Session Hi-Jacking Mika Koivisto 6 de Outubro de 2009 10:27
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 14 de Outubro de 2009 12:53
RE: Liferay Security Vulnerability: Session Hi-Jacking Olaf Kock 6 de Outubro de 2009 11:42
RE: Liferay Security Vulnerability: Session Hi-Jacking Lisa Simpson 6 de Outubro de 2009 13:09
RE: Liferay Security Vulnerability: Session Hi-Jacking Olaf Kock 6 de Outubro de 2009 11:35
RE: Liferay Security Vulnerability: Session Hi-Jacking Fuad Efendi 19 de Outubro de 2009 14:15
RE: Liferay Security Vulnerability: Session Hi-Jacking Michael Poznecki 14 de Dezembro de 2009 11:49
RE: Liferay Security Vulnerability: Session Hi-Jacking Krati Gupta 27 de Julho de 2010 02:10
RE: Liferay Security Vulnerability: Session Hi-Jacking Johan de jong 16 de Outubro de 2012 03:17
RE: Liferay Security Vulnerability: Session Hi-Jacking Mika Koivisto 16 de Outubro de 2012 12:04
RE: Liferay Security Vulnerability: Session Hi-Jacking Luiz Henrique Grossl 18 de Janeiro de 2013 09:15
Fuad Efendi
Liferay Security Vulnerability: Session Hi-Jacking
27 de Agosto de 2009 09:13
Resposta

Fuad Efendi

Ranking: Regular Member

Mensagens: 148

Data de entrada: 5 de Abril de 2007

Mensagens recentes

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 de Agosto de 2009 09:20
Resposta

Lisa Simpson

Ranking: Liferay Legend

Mensagens: 2034

Data de entrada: 5 de Março de 2009

Mensagens recentes

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 de Agosto de 2009 09:59
Resposta

Fuad Efendi

Ranking: Regular Member

Mensagens: 148

Data de entrada: 5 de Abril de 2007

Mensagens recentes

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 de Agosto de 2009 23:56
Resposta

Aritz Galdos

Ranking: Expert

Mensagens: 397

Data de entrada: 15 de Maio de 2007

Mensagens recentes

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 de Setembro de 2009 11:52
Resposta

Lisa Simpson

Ranking: Liferay Legend

Mensagens: 2034

Data de entrada: 5 de Março de 2009

Mensagens recentes

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 de Outubro de 2009 09:41
Resposta

Fuad Efendi

Ranking: Regular Member

Mensagens: 148

Data de entrada: 5 de Abril de 2007

Mensagens recentes

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 de Outubro de 2009 11:59
Resposta

Lisa Simpson

Ranking: Liferay Legend

Mensagens: 2034

Data de entrada: 5 de Março de 2009

Mensagens recentes

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 de Outubro de 2009 09:34
Resposta

Fuad Efendi

Ranking: Regular Member

Mensagens: 148

Data de entrada: 5 de Abril de 2007

Mensagens recentes

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 de Outubro de 2009 09:50
Resposta

Lisa Simpson

Ranking: Liferay Legend

Mensagens: 2034

Data de entrada: 5 de Março de 2009

Mensagens recentes

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 de Outubro de 2009 10:27
Resposta

Mika Koivisto

LIFERAY STAFF

Ranking: Liferay Legend

Mensagens: 1499

Data de entrada: 7 de Agosto de 2006

Mensagens recentes

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 de Outubro de 2009 11:35
Resposta

Olaf Kock

LIFERAY STAFF

Ranking: Liferay Legend

Mensagens: 1797

Data de entrada: 23 de Setembro de 2008

Mensagens recentes

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 de Outubro de 2009 11:42
Resposta

Olaf Kock

LIFERAY STAFF

Ranking: Liferay Legend

Mensagens: 1797

Data de entrada: 23 de Setembro de 2008

Mensagens recentes

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 de Outubro de 2009 13:09
Resposta

Lisa Simpson

Ranking: Liferay Legend

Mensagens: 2034

Data de entrada: 5 de Março de 2009

Mensagens recentes

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 de Outubro de 2009 12:53
Resposta

Fuad Efendi

Ranking: Regular Member

Mensagens: 148

Data de entrada: 5 de Abril de 2007

Mensagens recentes

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 de Outubro de 2009 14:15
Resposta

Fuad Efendi

Ranking: Regular Member

Mensagens: 148

Data de entrada: 5 de Abril de 2007

Mensagens recentes

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 de Dezembro de 2009 11:49
Resposta

Michael Poznecki

Ranking: Expert

Mensagens: 301

Data de entrada: 10 de Dezembro de 2008

Mensagens recentes

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

Krati Gupta

Ranking: Regular Member

Mensagens: 113

Data de entrada: 5 de Dezembro de 2008

Mensagens recentes

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 de Outubro de 2012 03:17
Resposta

Johan de jong

Ranking: Junior Member

Mensagens: 35

Data de entrada: 6 de Fevereiro de 2012

Mensagens recentes

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 de Outubro de 2012 12:04
Resposta

Mika Koivisto

LIFERAY STAFF

Ranking: Liferay Legend

Mensagens: 1499

Data de entrada: 7 de Agosto de 2006

Mensagens recentes

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 de Janeiro de 2013 09:15
Resposta

Luiz Henrique Grossl

Ranking: New Member

Mensagens: 1

Data de entrada: 24 de Agosto de 2010

Mensagens recentes

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.