From: Hungerburg <pc...@my...> - 2013-01-16 13:04:46
|
Test prerequisits: 1) an xquery script somewhere in /exist/rest space, that outputs just the value of xmldb:get-current-user(), 2) the Firefox web-browser (maybe others). Test steps A: - In one tab (1), call up "who.xq", read "guest". - In another tab (2) log in to eXide as "admin" - Refresh (1), read "admin" - In (2) log out of eXide. - Refresh (1), read "guest" Finding A: It is debatable, whether REST should honour session STATE. ##### Test steps B: - In one tab (1), call up "who.xq", read "guest". - In another tab (2) log in to and out of eXide as "admin" - Quit the browser. - Restart the browser. - In tab (1) who.xq prints "admin", even after refresh. Finding B: In tab (1) who.xq should print "guest". After the restart the browser sends the cookie that was installed by eXide to "who.xq" in /exist/rest space, because the cookie is valid for top level /exist. Cookie: JSESSIONID=1tf9lg0zl5fzt12wnxe3uj1n2r; org.exist.login=deleted The browser does not send an "Authorization: Basic xxYYzz " header, yet the session is still enough to authentify "admin". Logging out of eXide, eXist sends the message: 401 Unauthorized, with a "Set-Cookie: org.exist.login=deleted;Path=/exist " header. This seems not sufficient to clear the authentication from the server side session. I did not check "Remember me" from the eXide prompt. To logout of eXide, I click the "Logged in as admin" link. -- peter |
From: Wolfgang M. <wol...@ex...> - 2013-01-16 13:31:08
|
If you did NOT check the "Remember me" in eXide, it will use the standard servlet session, which sets the JSESSIONID cookie and is managed by jetty. This has nothing to do with eXide and you should see the same effect if you log into the old admin web app or any other page. It's a standard feature of the servlet container. Once you logged in and the browser sends a valid JSESSIONID cookie, you'll execute queries with the session user. The browser does not distinguish between different windows. Contrary to this, if you check the "Remember me" checkbox in eXide or the dashboard, it will NOT use the servlet container's session management, but exchange one-time access tokens for every request. The advantage is: with this we can indeed create sessions which are unique for an app and do not interfere with other apps running in the same browser at the same time. The disadvantage is: the feature provides better protection against attacks than the standard servlet session and is thus quite sensible to out-of-sequence requests. This can be a challenge if you develop an AJAX site. So if you want to make sure you can have separate logins for different pages within the same browser, use the persistent login module with a short session duration. I considered doing this in eXide and the dashboard as well, but could not make the switch without breaking backwards compatibility. Wolfgang > Test prerequisits: 1) an xquery script somewhere in /exist/rest space, > that outputs just the value of xmldb:get-current-user(), 2) the Firefox > web-browser (maybe others). > > Test steps A: > - In one tab (1), call up "who.xq", read "guest". > - In another tab (2) log in to eXide as "admin" > - Refresh (1), read "admin" > - In (2) log out of eXide. > - Refresh (1), read "guest" > > Finding A: It is debatable, whether REST should honour session STATE. > > ##### > > Test steps B: > - In one tab (1), call up "who.xq", read "guest". > - In another tab (2) log in to and out of eXide as "admin" > - Quit the browser. > - Restart the browser. > - In tab (1) who.xq prints "admin", even after refresh. > > Finding B: In tab (1) who.xq should print "guest". After the restart the > browser sends the cookie that was installed by eXide to "who.xq" in > /exist/rest space, because the cookie is valid for top level /exist. > > Cookie: JSESSIONID=1tf9lg0zl5fzt12wnxe3uj1n2r; org.exist.login=deleted > > The browser does not send an "Authorization: Basic xxYYzz " header, yet > the session is still enough to authentify "admin". > > Logging out of eXide, eXist sends the message: 401 Unauthorized, with a > "Set-Cookie: org.exist.login=deleted;Path=/exist " header. This seems > not sufficient to clear the authentication from the server side session. > > I did not check "Remember me" from the eXide prompt. To logout of eXide, > I click the "Logged in as admin" link. > > -- > peter > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > Exist-open mailing list > Exi...@li... (mailto:Exi...@li...) > https://lists.sourceforge.net/lists/listinfo/exist-open |
From: Wolfgang M. <wol...@ex...> - 2013-01-16 13:52:02
|
> Logging out of eXide, eXist sends the message: 401 Unauthorized, with a > "Set-Cookie: org.exist.login=deleted;Path=/exist " header. This seems > not sufficient to clear the authentication from the server side session. Ok, I just fixed this one. The servlet engine's session was not removed, only eXide's own session. Wolfgang |
From: Adam R. <ad...@ex...> - 2013-01-31 11:22:58
|
>> Logging out of eXide, eXist sends the message: 401 Unauthorized, with a >> "Set-Cookie: org.exist.login=deleted;Path=/exist " header. This seems >> not sufficient to clear the authentication from the server side session. > > Ok, I just fixed this one. The servlet engine's session was not removed, only eXide's own session. Yup - can you also take a look at a previous email I sent you please where I think the cookie authentication is broken and see you get different results between RESTServer and XQueryServlet. I proposed a fix. I would like to know how to proceed with this... > Wolfgang > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Joe W. <jo...@gm...> - 2013-01-30 23:55:24
|
Hi Wolfgang, > Contrary to this, if you check the "Remember me" checkbox in eXide or the dashboard, it will NOT use the servlet container's session management, but exchange one-time access tokens for every request. The advantage is: with this we can indeed create sessions which are unique for an app and do not interfere with other apps running in the same browser at the same time. The disadvantage is: the feature provides better protection against attacks than the standard servlet session and is thus quite sensible to out-of-sequence requests. This can be a challenge if you develop an AJAX site. I've been following your work on the persistent login module. I'm curious to know: were the cookie stealing attacks you were guarding against with this latest update to "spring-style" authentication an issue only for non-SSL connections (since authentication is not handled over HTTPS in eXist-db out of the box), or do the cookie stealing attacks also affect SSL connections? (If there's some discussion how Spring's authentication avoids cookie stealing attacks that you referred to, could you post the link?) Thanks, Joe |
From: Wolfgang M. <wol...@ex...> - 2013-01-31 09:12:14
|
Hi Joe, > I've been following your work on the persistent login module. I'm > curious to know: were the cookie stealing attacks you were guarding > against with this latest update to "spring-style" authentication an > issue only for non-SSL connections (since authentication is not > handled over HTTPS in eXist-db out of the box), or do the cookie > stealing attacks also affect SSL connections? SSL-connections are normally expected to be save. The browser will keep cookies in a separate space and you cannot easily extract them from a request. Things look different if the connection is not encrypted though: maintaining a user session from a web browser over a non-SSL connection will never be save. If someone listens on your connection or can physically access your machine, he may extract the session cookie and use it. You can get some protection by using short-lived logins, thus limiting the time window during which an attacker could impersonate you. This is very inconvenient for the user though. The persistent login mechanism I chose after reading about various approaches makes it slightly more difficult for an ears dropper: instead of using a single login cookie for the duration of a session, a new login token is sent with every HTTP response. The token will only be valid for the next request and is deleted afterwards. If a token is sent which does not match the expected sequence, we assume an attack attempt and kill the session. Still, an attacker may wait until you grab a coffee, take your cookie and send a few requests before you return and recognize the attack. It is thus still important to log out when you are not actively working. The mechanism I chose is described here: http://jaspan.com/improved_persistent_login_cookie_best_practice The implementation follows the one in Spring Security: http://static.springsource.org/spring-security/site/docs/3.2.0.M1/reference/remember-me.html Again, no user session is completely save unless you use SSL. Unfortunately we cannot enable SSL for the standard install out of the box. This has to be done by the user. Wolfgang |
From: Joe W. <jo...@gm...> - 2013-01-31 12:34:52
|
Hi Wolfgang, > SSL-connections are normally expected to be save. The browser will keep cookies in a separate space and you cannot easily extract them from a request. ... > The persistent login mechanism I chose after reading about various approaches makes it slightly more difficult for an ears dropper: instead of using a single login cookie for the duration of a session, a new login token is sent with every HTTP response. The token will only be valid for the next request and is deleted afterwards. If a token is sent which does not match the expected sequence, we assume an attack attempt and kill the session. Still, an attacker may wait until you grab a coffee, take your cookie and send a few requests before you return and recognize the attack. It is thus still important to log out when you are not actively working. Great, thank you for all this info and reference material. The one-time-use cookie approach helps makes sense as an attempt to circumvent lazy cookie hijacking attacks. > Again, no user session is completely save unless you use SSL. Unfortunately we cannot enable SSL for the standard install out of the box. This has to be done by the user. I'm curious about this too. Why is enabling SSL by default not possible? (All I can think is that it's not possible to generate a new keystore during installation?) Thanks, Joe |
From: Adam R. <ad...@ex...> - 2013-01-31 12:49:09
|
I am also interested to know - I thought we did enable SSL as well as non-SSL already? On 31 January 2013 12:34, Joe Wicentowski <jo...@gm...> wrote: > Hi Wolfgang, > >> SSL-connections are normally expected to be save. The browser will keep cookies in a separate space and you cannot easily extract them from a request. > ... >> The persistent login mechanism I chose after reading about various approaches makes it slightly more difficult for an ears dropper: instead of using a single login cookie for the duration of a session, a new login token is sent with every HTTP response. The token will only be valid for the next request and is deleted afterwards. If a token is sent which does not match the expected sequence, we assume an attack attempt and kill the session. Still, an attacker may wait until you grab a coffee, take your cookie and send a few requests before you return and recognize the attack. It is thus still important to log out when you are not actively working. > > Great, thank you for all this info and reference material. The > one-time-use cookie approach helps makes sense as an attempt to > circumvent lazy cookie hijacking attacks. > >> Again, no user session is completely save unless you use SSL. Unfortunately we cannot enable SSL for the standard install out of the box. This has to be done by the user. > > I'm curious about this too. Why is enabling SSL by default not > possible? (All I can think is that it's not possible to generate a > new keystore during installation?) > > Thanks, > Joe > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Wolfgang M. <wol...@ex...> - 2013-01-31 13:26:23
|
> I am also interested to know - I thought we did enable SSL as well as > non-SSL already? Yes, right, it is enabled, but if I remember well: unless you properly install a certificate, some browsers will not only warn but refuse to connect. Wolfgang |
From: Dannes W. <da...@ex...> - 2013-01-31 15:20:56
|
Wolfgang is correct, most browser handle self-signed certificates in a not so nice way. It will make your customer go away :-) besides: there is one certificate for all exist-db instances ; this is a security risk as well since the public/private keys are available for anyone..... D. On Thu, Jan 31, 2013 at 2:26 PM, Wolfgang Meier <wol...@ex...>wrote: > > I am also interested to know - I thought we did enable SSL as well as > > non-SSL already? > > Yes, right, it is enabled, but if I remember well: unless you properly > install a certificate, some browsers will not only warn but refuse to > connect. > -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Joern T. <joe...@gm...> - 2013-02-05 07:37:09
|
Maybe that's beyond the scope of what eXist can fix but talking to a security expert recently i only can summarize that SSL is *seriously* broken since the root CA attacks. Actually SSL security is not more than perceived security today. If you're really reaching for real security your only option today is to setup your own root CA and make your customers trust you (by accepting your root cert in the browser). That's obviously not very satisfying but the only option when seeking real security. On Thu, Jan 31, 2013 at 4:20 PM, Dannes Wessels <da...@ex...> wrote: > Wolfgang is correct, most browser handle self-signed certificates in a not > so nice way. It will make your customer go away :-) > > besides: there is one certificate for all exist-db instances ; this is a > security risk as well since the public/private keys are available for > anyone..... > > D. > > > On Thu, Jan 31, 2013 at 2:26 PM, Wolfgang Meier <wol...@ex...>wrote: > >> > I am also interested to know - I thought we did enable SSL as well as >> > non-SSL already? >> >> Yes, right, it is enabled, but if I remember well: unless you properly >> install a certificate, some browsers will not only warn but refuse to >> connect. >> > > > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > > |
From: Hungerburg <pc...@my...> - 2013-02-05 08:46:37
|
Am 2013-02-05 08:37, schrieb Joern Turner: > Maybe that's beyond the scope of what eXist can fix but talking to a > security expert recently i only can summarize that SSL is *seriously* > broken since the root CA attacks. Actually SSL security is not more than > perceived security today. > > If you're really reaching for real security your only option today is to > setup your own root CA and make your customers trust you (by accepting > your root cert in the browser). That's obviously not very satisfying but > the only option when seeking real security. The way I understand the SSL problem: If security is a top issue in ones environment, the browser/agent additionally should NOT accept any other CA than THAT one. (Or any one, that is fully trusted; as any CA can be used to get into the middle between the peers of any SSL connection.) If that requirement is too steep, there are browser plugins, that warn the user/principal, when the CA changes for a known host, which is a bit like SSH, but may require a second channel to check eg. a fingerprint on the first connection. -- Peter |