You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Andrew Turner <gr...@hotmail.com> on 2009/12/02 10:24:13 UTC
Session stealing with wicket-auth-roles
Good morning all,
I'm hoping I've misconfigured something in my application, but we seem to be prone to session stealing in our wicket application. We're using wicket-auth-roles to provide the security, and if you are able to access the jsessionid you can get another machine to log straight into the application as the intercepted user. We're using HTTPS for the communication, so hopefully the likelihood of this occurring is quite small, but we are still being forced to contemplate rewriting the security layer (which I want to avoid if possible).
So, my question, have I misconfigured something, or is it just not possible to prevent this sort of attack when using wicket-auth-roles?
I've managed to create a completely stripped-down app that still has the problem, below is the AuthenticatedWhenSession implementation.
public class HelloWorldWebSession extends AuthenticatedWebSession {
public HelloWorldWebSession(Request request) { super(request); }
public boolean authenticate(String username, String password) { return "helloUser".equals(username) && "password".equals(password); }
public Roles getRoles() { return isSignedIn() ? new Roles(Roles.USER) : null; }
}
And the simple page:
@AuthorizeInstantiation("USER")
public class HelloWorldHomePage extends WebPage { }
And the application:
public class HelloWorldApplication extends AuthenticatedWebApplication {
protected void init() {
super.init();
mountBookmarkablePage("home", HelloWorldHomePage.class);
mountBookmarkablePage("signin", SignInPage.class);
}
protected Class<? extends WebPage> getSignInPageClass() { return SignInPage.class; }
protected Class<? extends AuthenticatedWebSession> getWebSessionClass() { return HelloWorldWebSession.class; }
public Class<? extends Page> getHomePage() { return HelloWorldHomePage.class; }
}
The URL below, once logged in on one machine, could then be used on multiple machines to bypass the security layer.
http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_URL/COOKIE>
Many Thanks
Andy
_________________________________________________________________
Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
http://clk.atdmt.com/UKM/go/186394592/direct/01/
Re: Session stealing with wicket-auth-roles
Posted by Marat Radchenko <sl...@gmail.com>.
2009/12/2 Andrew Turner <gr...@hotmail.com>:
>
>
> Good morning all,
>
> I'm hoping I've misconfigured something in my application, but we seem to be prone to session stealing in our wicket application. We're using wicket-auth-roles to provide the security, and if you are able to access the jsessionid you can get another machine to log straight into the application as the intercepted user. We're using HTTPS for the communication, so hopefully the likelihood of this occurring is quite small, but we are still being forced to contemplate rewriting the security layer (which I want to avoid if possible).
>
> So, my question, have I misconfigured something, or is it just not possible to prevent this sort of attack when using wicket-auth-roles?
>
> I've managed to create a completely stripped-down app that still has the problem, below is the AuthenticatedWhenSession implementation.
>
> public class HelloWorldWebSession extends AuthenticatedWebSession {
> public HelloWorldWebSession(Request request) { super(request); }
> public boolean authenticate(String username, String password) { return "helloUser".equals(username) && "password".equals(password); }
> public Roles getRoles() { return isSignedIn() ? new Roles(Roles.USER) : null; }
> }
>
> And the simple page:
>
> @AuthorizeInstantiation("USER")
> public class HelloWorldHomePage extends WebPage { }
>
> And the application:
>
> public class HelloWorldApplication extends AuthenticatedWebApplication {
> protected void init() {
> super.init();
> mountBookmarkablePage("home", HelloWorldHomePage.class);
> mountBookmarkablePage("signin", SignInPage.class);
> }
>
> protected Class<? extends WebPage> getSignInPageClass() { return SignInPage.class; }
> protected Class<? extends AuthenticatedWebSession> getWebSessionClass() { return HelloWorldWebSession.class; }
> public Class<? extends Page> getHomePage() { return HelloWorldHomePage.class; }
> }
>
> The URL below, once logged in on one machine, could then be used on multiple machines to bypass the security layer.
>
> http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_URL/COOKIE>
>
> Many Thanks
> Andy
>
>
> _________________________________________________________________
> Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
> http://clk.atdmt.com/UKM/go/186394592/direct/01/
Man, just configure you webserver properly so it doesn't append
jsessionid to urls. Wicket has nothing to do with session management.
Jetty (web.xml):
<context-param>
<param-name>org.mortbay.jetty.servlet.SessionURL</param-name>
<param-value>none</param-value>
</context-param>
Resin (resin-web.xml):
<web-app id='...'>
<session-config enable-cookies='true' enable-url-rewriting='false' />
</web-app>
Other:
use your webserver docs.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session stealing with wicket-auth-roles
Posted by nino martinez wael <ni...@gmail.com>.
Cant you use
http://www.mkyong.com/wicket/how-do-encrypt-encode-url-in-wicket/
But I guess it might still get the session id appended..?
2009/12/2 Loritsch, Berin C. <Be...@gd-ais.com>
> I too would like to know the Wicket answer. The problem is that
> JSESSIONID is how the Servlet container differentiates the session with
> the user. It's part of the spec since the beginning. Because it is
> well known and certain browsers (Firefox, representing over a third of
> browser clients) make it pretty easy to look at the cookies it has
> become a known weakness to people who want to do bad things.
>
> Now, if the entire interaction is done with HTTPS, theoretically you
> would be able to use the SSL session ID to match sessions. That would
> be a configuration setting on your Servlet container.
>
> The solution that some frameworks and roll your own security folks have
> come up with (like Ruby on Rails) is to use a secondary token as a salt
> for a secondary token. Rails uses this token for all POST requests and
> uses a constant time comparison for the token (another topic
> altogether). Of course, Rails stores all session data in a Cookie by
> default, encrypted and hashed with the secondary token. It makes it
> more difficult to steal a session that way. An approach similar to this
> (without storing session data in a cookie) can be done using a
> ServletFilter.
>
> The alternative I've seen is to change the secondary token periodically
> or every request. The problem with this solution is that you break the
> back button when the token changes. At the very least, the secondary
> token should be generated based on requestor information (IP address,
> user agent, etc.). That way the token is not simply a matter of simply
> matching the JSESSIONID string against a hash. You are recreating the
> master token the same way and comparing it with what you received.
>
> To summarize, I would most likely create a ServletFilter to handle the
> secondary token handling. The secondary token would be a SHA-1 hash of
> an application salt (random characters at least the length of an SHA-1),
> the user agent, and the requesting IP address, and the Servlet session
> ID. The ServletFilter either throws a 403 response, or invalidates the
> session if the newly generated key does not match the secondary token
> provided. Essentially, the user would have to be behind the same
> firewall/gateway, have the same exact browser and patch level, and the
> session id to successfully steal a session. Even within an organization
> the differences in user agent strings for Internet Explorer at any
> version vary greatly.
>
> Additionally, I would use the ServletFilter to actively reject automated
> clients. If the system lives in SSL, this is a valid approach because
> you don't necessarily want the contents indexed. You'd be surprised how
> many poorly behaving web crawlers there are out there. Many of them are
> home-brewed scripts that spider your site, ignoring your robots.txt
> file--even on private networks.
>
> -----Original Message-----
> From: Andrew Turner [mailto:grim_toaster@hotmail.com]
> Sent: Wednesday, December 02, 2009 4:24 AM
> To: users@wicket.apache.org
> Subject: Session stealing with wicket-auth-roles
>
>
>
> Good morning all,
>
> I'm hoping I've misconfigured something in my application, but we seem
> to be prone to session stealing in our wicket application. We're using
> wicket-auth-roles to provide the security, and if you are able to access
> the jsessionid you can get another machine to log straight into the
> application as the intercepted user. We're using HTTPS for the
> communication, so hopefully the likelihood of this occurring is quite
> small, but we are still being forced to contemplate rewriting the
> security layer (which I want to avoid if possible).
>
> So, my question, have I misconfigured something, or is it just not
> possible to prevent this sort of attack when using wicket-auth-roles?
>
> I've managed to create a completely stripped-down app that still has the
> problem, below is the AuthenticatedWhenSession implementation.
>
> public class HelloWorldWebSession extends AuthenticatedWebSession {
> public HelloWorldWebSession(Request request) { super(request); }
> public boolean authenticate(String username, String password) {
> return "helloUser".equals(username) && "password".equals(password); }
> public Roles getRoles() { return isSignedIn() ? new
> Roles(Roles.USER) : null; }
> }
>
> And the simple page:
>
> @AuthorizeInstantiation("USER")
> public class HelloWorldHomePage extends WebPage { }
>
> And the application:
>
> public class HelloWorldApplication extends AuthenticatedWebApplication {
> protected void init() {
> super.init();
> mountBookmarkablePage("home", HelloWorldHomePage.class);
> mountBookmarkablePage("signin", SignInPage.class);
> }
>
> protected Class<? extends WebPage> getSignInPageClass() { return
> SignInPage.class; }
> protected Class<? extends AuthenticatedWebSession>
> getWebSessionClass() { return HelloWorldWebSession.class; }
> public Class<? extends Page> getHomePage() { return
> HelloWorldHomePage.class; }
> }
>
> The URL below, once logged in on one machine, could then be used on
> multiple machines to bypass the security layer.
>
> http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_
> URL/COOKIE>
>
> Many Thanks
> Andy
>
>
> _________________________________________________________________
> Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
> http://clk.atdmt.com/UKM/go/186394592/direct/01/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Session stealing with wicket-auth-roles
Posted by "Loritsch, Berin C." <Be...@gd-ais.com>.
I too would like to know the Wicket answer. The problem is that
JSESSIONID is how the Servlet container differentiates the session with
the user. It's part of the spec since the beginning. Because it is
well known and certain browsers (Firefox, representing over a third of
browser clients) make it pretty easy to look at the cookies it has
become a known weakness to people who want to do bad things.
Now, if the entire interaction is done with HTTPS, theoretically you
would be able to use the SSL session ID to match sessions. That would
be a configuration setting on your Servlet container.
The solution that some frameworks and roll your own security folks have
come up with (like Ruby on Rails) is to use a secondary token as a salt
for a secondary token. Rails uses this token for all POST requests and
uses a constant time comparison for the token (another topic
altogether). Of course, Rails stores all session data in a Cookie by
default, encrypted and hashed with the secondary token. It makes it
more difficult to steal a session that way. An approach similar to this
(without storing session data in a cookie) can be done using a
ServletFilter.
The alternative I've seen is to change the secondary token periodically
or every request. The problem with this solution is that you break the
back button when the token changes. At the very least, the secondary
token should be generated based on requestor information (IP address,
user agent, etc.). That way the token is not simply a matter of simply
matching the JSESSIONID string against a hash. You are recreating the
master token the same way and comparing it with what you received.
To summarize, I would most likely create a ServletFilter to handle the
secondary token handling. The secondary token would be a SHA-1 hash of
an application salt (random characters at least the length of an SHA-1),
the user agent, and the requesting IP address, and the Servlet session
ID. The ServletFilter either throws a 403 response, or invalidates the
session if the newly generated key does not match the secondary token
provided. Essentially, the user would have to be behind the same
firewall/gateway, have the same exact browser and patch level, and the
session id to successfully steal a session. Even within an organization
the differences in user agent strings for Internet Explorer at any
version vary greatly.
Additionally, I would use the ServletFilter to actively reject automated
clients. If the system lives in SSL, this is a valid approach because
you don't necessarily want the contents indexed. You'd be surprised how
many poorly behaving web crawlers there are out there. Many of them are
home-brewed scripts that spider your site, ignoring your robots.txt
file--even on private networks.
-----Original Message-----
From: Andrew Turner [mailto:grim_toaster@hotmail.com]
Sent: Wednesday, December 02, 2009 4:24 AM
To: users@wicket.apache.org
Subject: Session stealing with wicket-auth-roles
Good morning all,
I'm hoping I've misconfigured something in my application, but we seem
to be prone to session stealing in our wicket application. We're using
wicket-auth-roles to provide the security, and if you are able to access
the jsessionid you can get another machine to log straight into the
application as the intercepted user. We're using HTTPS for the
communication, so hopefully the likelihood of this occurring is quite
small, but we are still being forced to contemplate rewriting the
security layer (which I want to avoid if possible).
So, my question, have I misconfigured something, or is it just not
possible to prevent this sort of attack when using wicket-auth-roles?
I've managed to create a completely stripped-down app that still has the
problem, below is the AuthenticatedWhenSession implementation.
public class HelloWorldWebSession extends AuthenticatedWebSession {
public HelloWorldWebSession(Request request) { super(request); }
public boolean authenticate(String username, String password) {
return "helloUser".equals(username) && "password".equals(password); }
public Roles getRoles() { return isSignedIn() ? new
Roles(Roles.USER) : null; }
}
And the simple page:
@AuthorizeInstantiation("USER")
public class HelloWorldHomePage extends WebPage { }
And the application:
public class HelloWorldApplication extends AuthenticatedWebApplication {
protected void init() {
super.init();
mountBookmarkablePage("home", HelloWorldHomePage.class);
mountBookmarkablePage("signin", SignInPage.class);
}
protected Class<? extends WebPage> getSignInPageClass() { return
SignInPage.class; }
protected Class<? extends AuthenticatedWebSession>
getWebSessionClass() { return HelloWorldWebSession.class; }
public Class<? extends Page> getHomePage() { return
HelloWorldHomePage.class; }
}
The URL below, once logged in on one machine, could then be used on
multiple machines to bypass the security layer.
http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_
URL/COOKIE>
Many Thanks
Andy
_________________________________________________________________
Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
http://clk.atdmt.com/UKM/go/186394592/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
AW: Session stealing with wicket-auth-roles
Posted by "Giambalvo, Christian" <Ch...@excelsisnet.com>.
Hmm, for me it doesn't work.
I mount the pages via:
this.mount("/pages/secure", PackageName.forClass(this.getHomePage()));
If I try to access the page from machine B with the same jessionid as machine A, then I get redirected to LoginPage.
-----Ursprüngliche Nachricht-----
Von: Andrew Turner [mailto:grim_toaster@hotmail.com]
Gesendet: Mittwoch, 2. Dezember 2009 10:24
An: users@wicket.apache.org
Betreff: Session stealing with wicket-auth-roles
Good morning all,
I'm hoping I've misconfigured something in my application, but we seem to be prone to session stealing in our wicket application. We're using wicket-auth-roles to provide the security, and if you are able to access the jsessionid you can get another machine to log straight into the application as the intercepted user. We're using HTTPS for the communication, so hopefully the likelihood of this occurring is quite small, but we are still being forced to contemplate rewriting the security layer (which I want to avoid if possible).
So, my question, have I misconfigured something, or is it just not possible to prevent this sort of attack when using wicket-auth-roles?
I've managed to create a completely stripped-down app that still has the problem, below is the AuthenticatedWhenSession implementation.
public class HelloWorldWebSession extends AuthenticatedWebSession {
public HelloWorldWebSession(Request request) { super(request); }
public boolean authenticate(String username, String password) { return "helloUser".equals(username) && "password".equals(password); }
public Roles getRoles() { return isSignedIn() ? new Roles(Roles.USER) : null; }
}
And the simple page:
@AuthorizeInstantiation("USER")
public class HelloWorldHomePage extends WebPage { }
And the application:
public class HelloWorldApplication extends AuthenticatedWebApplication {
protected void init() {
super.init();
mountBookmarkablePage("home", HelloWorldHomePage.class);
mountBookmarkablePage("signin", SignInPage.class);
}
protected Class<? extends WebPage> getSignInPageClass() { return SignInPage.class; }
protected Class<? extends AuthenticatedWebSession> getWebSessionClass() { return HelloWorldWebSession.class; }
public Class<? extends Page> getHomePage() { return HelloWorldHomePage.class; }
}
The URL below, once logged in on one machine, could then be used on multiple machines to bypass the security layer.
http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_URL/COOKIE>
Many Thanks
Andy
_________________________________________________________________
Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
http://clk.atdmt.com/UKM/go/186394592/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session stealing with wicket-auth-roles
Posted by Erik van Oosten <e....@grons.nl>.
Thats basically the same code as on
http://randomcoder.com/articles/jsessionid-considered-harmful.
OWASP also has a good deal to say about sessions:
http://www.owasp.org/index.php/Session_Management
Regards,
Erik.
James Carman wrote:
> The Seam folks have a "fix" for removing JSESSIONID from the URLs, too:
>
> http://seamframework.org/Documentation/RemovingJSESSIONIDFromYourURLsAndFixingScache
>
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session stealing with wicket-auth-roles
Posted by James Carman <jc...@carmanconsulting.com>.
The Seam folks have a "fix" for removing JSESSIONID from the URLs, too:
http://seamframework.org/Documentation/RemovingJSESSIONIDFromYourURLsAndFixingScache
On Wed, Dec 2, 2009 at 9:31 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> This is not a Wicket issue. However, there is a good discussion on
> the topic here:
>
> http://old.nabble.com/JSESSIONID-hijacking-td22492701.html
>
> What application server are you using?
>
> On Wed, Dec 2, 2009 at 4:24 AM, Andrew Turner <gr...@hotmail.com> wrote:
>>
>>
>> Good morning all,
>>
>> I'm hoping I've misconfigured something in my application, but we seem to be prone to session stealing in our wicket application. We're using wicket-auth-roles to provide the security, and if you are able to access the jsessionid you can get another machine to log straight into the application as the intercepted user. We're using HTTPS for the communication, so hopefully the likelihood of this occurring is quite small, but we are still being forced to contemplate rewriting the security layer (which I want to avoid if possible).
>>
>> So, my question, have I misconfigured something, or is it just not possible to prevent this sort of attack when using wicket-auth-roles?
>>
>> I've managed to create a completely stripped-down app that still has the problem, below is the AuthenticatedWhenSession implementation.
>>
>> public class HelloWorldWebSession extends AuthenticatedWebSession {
>> public HelloWorldWebSession(Request request) { super(request); }
>> public boolean authenticate(String username, String password) { return "helloUser".equals(username) && "password".equals(password); }
>> public Roles getRoles() { return isSignedIn() ? new Roles(Roles.USER) : null; }
>> }
>>
>> And the simple page:
>>
>> @AuthorizeInstantiation("USER")
>> public class HelloWorldHomePage extends WebPage { }
>>
>> And the application:
>>
>> public class HelloWorldApplication extends AuthenticatedWebApplication {
>> protected void init() {
>> super.init();
>> mountBookmarkablePage("home", HelloWorldHomePage.class);
>> mountBookmarkablePage("signin", SignInPage.class);
>> }
>>
>> protected Class<? extends WebPage> getSignInPageClass() { return SignInPage.class; }
>> protected Class<? extends AuthenticatedWebSession> getWebSessionClass() { return HelloWorldWebSession.class; }
>> public Class<? extends Page> getHomePage() { return HelloWorldHomePage.class; }
>> }
>>
>> The URL below, once logged in on one machine, could then be used on multiple machines to bypass the security layer.
>>
>> http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_URL/COOKIE>
>>
>> Many Thanks
>> Andy
>>
>>
>> _________________________________________________________________
>> Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
>> http://clk.atdmt.com/UKM/go/186394592/direct/01/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Session stealing with wicket-auth-roles
Posted by James Carman <jc...@carmanconsulting.com>.
This is not a Wicket issue. However, there is a good discussion on
the topic here:
http://old.nabble.com/JSESSIONID-hijacking-td22492701.html
What application server are you using?
On Wed, Dec 2, 2009 at 4:24 AM, Andrew Turner <gr...@hotmail.com> wrote:
>
>
> Good morning all,
>
> I'm hoping I've misconfigured something in my application, but we seem to be prone to session stealing in our wicket application. We're using wicket-auth-roles to provide the security, and if you are able to access the jsessionid you can get another machine to log straight into the application as the intercepted user. We're using HTTPS for the communication, so hopefully the likelihood of this occurring is quite small, but we are still being forced to contemplate rewriting the security layer (which I want to avoid if possible).
>
> So, my question, have I misconfigured something, or is it just not possible to prevent this sort of attack when using wicket-auth-roles?
>
> I've managed to create a completely stripped-down app that still has the problem, below is the AuthenticatedWhenSession implementation.
>
> public class HelloWorldWebSession extends AuthenticatedWebSession {
> public HelloWorldWebSession(Request request) { super(request); }
> public boolean authenticate(String username, String password) { return "helloUser".equals(username) && "password".equals(password); }
> public Roles getRoles() { return isSignedIn() ? new Roles(Roles.USER) : null; }
> }
>
> And the simple page:
>
> @AuthorizeInstantiation("USER")
> public class HelloWorldHomePage extends WebPage { }
>
> And the application:
>
> public class HelloWorldApplication extends AuthenticatedWebApplication {
> protected void init() {
> super.init();
> mountBookmarkablePage("home", HelloWorldHomePage.class);
> mountBookmarkablePage("signin", SignInPage.class);
> }
>
> protected Class<? extends WebPage> getSignInPageClass() { return SignInPage.class; }
> protected Class<? extends AuthenticatedWebSession> getWebSessionClass() { return HelloWorldWebSession.class; }
> public Class<? extends Page> getHomePage() { return HelloWorldHomePage.class; }
> }
>
> The URL below, once logged in on one machine, could then be used on multiple machines to bypass the security layer.
>
> http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_URL/COOKIE>
>
> Many Thanks
> Andy
>
>
> _________________________________________________________________
> Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
> http://clk.atdmt.com/UKM/go/186394592/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Session stealing with wicket-auth-roles
Posted by Andrew Turner <gr...@hotmail.com>.
Marvellous, thanks for the input folks. So, in a nutshell, what we're basically saying is that when using Wicket we recommend HTTPS and disabling URL rewrite (we are using weblogic and I presumed one of the other settings should have disabled URL rewrite, the fool I am, cookie-secure seemed to do nothing!). It's still possible to steal the session, but I've just got to rely on the users not doing anything too silly now!
The only other thing I thought may have been a problem is that as I'm using wicket-auth-roles it doesn't use the standard jee authentication, which I presume is where weblogic gets involved and sets its own secure-cookie. Oh well, at least now we should be able to prevent people emailing each other their sessions!
Thanks again.
Andy
> From: grim_toaster@hotmail.com
> To: users@wicket.apache.org
> Subject: Session stealing with wicket-auth-roles
> Date: Wed, 2 Dec 2009 09:24:13 +0000
>
>
>
> Good morning all,
>
> I'm hoping I've misconfigured something in my application, but we seem to be prone to session stealing in our wicket application. We're using wicket-auth-roles to provide the security, and if you are able to access the jsessionid you can get another machine to log straight into the application as the intercepted user. We're using HTTPS for the communication, so hopefully the likelihood of this occurring is quite small, but we are still being forced to contemplate rewriting the security layer (which I want to avoid if possible).
>
> So, my question, have I misconfigured something, or is it just not possible to prevent this sort of attack when using wicket-auth-roles?
>
> I've managed to create a completely stripped-down app that still has the problem, below is the AuthenticatedWhenSession implementation.
>
> public class HelloWorldWebSession extends AuthenticatedWebSession {
> public HelloWorldWebSession(Request request) { super(request); }
> public boolean authenticate(String username, String password) { return "helloUser".equals(username) && "password".equals(password); }
> public Roles getRoles() { return isSignedIn() ? new Roles(Roles.USER) : null; }
> }
>
> And the simple page:
>
> @AuthorizeInstantiation("USER")
> public class HelloWorldHomePage extends WebPage { }
>
> And the application:
>
> public class HelloWorldApplication extends AuthenticatedWebApplication {
> protected void init() {
> super.init();
> mountBookmarkablePage("home", HelloWorldHomePage.class);
> mountBookmarkablePage("signin", SignInPage.class);
> }
>
> protected Class<? extends WebPage> getSignInPageClass() { return SignInPage.class; }
> protected Class<? extends AuthenticatedWebSession> getWebSessionClass() { return HelloWorldWebSession.class; }
> public Class<? extends Page> getHomePage() { return HelloWorldHomePage.class; }
> }
>
> The URL below, once logged in on one machine, could then be used on multiple machines to bypass the security layer.
>
> http://localhost:9090/HelloWorld/home;jsessionid=<SESSION_ID_TAKEN_FROM_URL/COOKIE>
>
> Many Thanks
> Andy
>
>
> _________________________________________________________________
> Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
> http://clk.atdmt.com/UKM/go/186394592/direct/01/
_________________________________________________________________
Got more than one Hotmail account? Save time by linking them together
http://clk.atdmt.com/UKM/go/186394591/direct/01/