Yes, they are readable - but they are not directly visible for example
in referrer urls on other websites....

So what do you do, to protect your applications? Or are you mainly doing intranet applications where those issues are not important?


-------- Original-Nachricht --------
> Datum: Mon, 26 May 2008 14:22:50 -0700
> Von: "Kalle Korhonen" <kalle.o.korhonen@gmail...
> An: users@trails...
> Betreff: Re: [trails-users] Trails Security unsecure ???

> On Mon, May 26, 2008 at 1:00 PM, Tobias Marx <superoverdrive@gmx...
> wrote:
> 
> > The problem is though, that anyone can easily hijack your session this
> > way....you just need to visit another website and then, the URL
> including
> > your session id is included in the referrer url...so in this respect all
> > Trails security applications have a "security hole" if you dont do
> anything
> > else.....
> 
> 
> This is not Trails-specific, it's standard servlet-based application
> behavior.
> 
> 
> > There are some frameworks that also change the session id on every
> > request....anyway, but I still think cookies is the safest way - but
> there
> > is no way to disable them in the application...you can only use
> > jk_stripsession in Tomcat.
> 
> 
> If you are truly worried about this, do not rely on cookies being any more
> secure. The headers just as easily readable as the url. As I said, you can
> disable url rewriting by writing a simple servlet filter.
> 
> Kalle
> 
> 
> 
> > -------- Original-Nachricht --------
> > > Datum: Mon, 26 May 2008 11:56:43 -0700
> > > Von: "Kalle Korhonen" <kalle.o.korhonen@gmail...
> > > An: users@trails...
> > > Betreff: Re: [trails-users] Trails Security unsecure ???
> >
> > > Obviously session ids do not change with every request; that's why
> they
> > > are
> > > *session* ids. The servlet spec defines cookies and url rewriting as
> the
> > > methods for session tracking and it doesn't declare any way to
> instruct
> > > the
> > > container to only use either one or the other. Containers may allow to
> > > configure it. For example, Tomcat allows you to disable cookies, but
> not
> > > url
> > > re-writing
> (http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
> > ).
> > > Naturally though, you can choose to not allow sessions at all. You can
> > > disable url re-writing manually with a simple filter, but passing in
> the
> > > jsessionid in the request header (as in cookie) isn't considerably
> more
> > > secure than passing it in the url. Use https only if you want to
> secure
> > > all
> > > communication to your site.
> > >
> > > Kalle
> > >
> > >
> > > On Mon, May 26, 2008 at 10:15 AM, Tobias Marx <superoverdrive@gmx...
> > > wrote:
> > >
> > > > Yes, this is what I did now...but what about the automatic
> session-id
> > > > fallback? Or is it possible to switch this off ?
> > > >
> > > > Session IDs are bad - unless they change with every
> request....and/or
> > > are
> > > > ip address related (but ips change, too).
> > > >
> > > >
> > > > -------- Original-Nachricht --------
> > > > > Datum: Mon, 26 May 2008 09:26:56 -0700
> > > > > Von: "Kalle Korhonen" <kalle.o.korhonen@gmail...
> > > > > An: users@trails...
> > > > > Betreff: Re: [trails-users] Trails Security unsecure ???
> > > >
> > > > > Use POST to send the login form via https. These certainly are
> easily
> > > > > configurable but not necessarily the best defaults when you first
> > > start
> > > > > developing a web application - which is why Trails and web app
> > > frameworks
> > > > > typically have the simplest options for demonstration purposes.
> > > > >
> > > > > Kalle
> > > > >
> > > > >
> > > > > On Mon, May 26, 2008 at 7:41 AM, Tobias Marx
> <superoverdrive@gmx...
> > > > > wrote:
> > > > >
> > > > > > There are some issues about Trails Security that might maybe
> > > > > > be configurable - I hope they are.
> > > > > >
> > > > > > By default, Trails Security is quite unsecure:
> > > > > >
> > > > > > 1. Username/password on the login page are passed via GET in the
> > URL
> > > > !!!
> > > > > > 2. If Cookies are disabled, Session IDs are used - that are
> easily
> > > > > > hijackable....
> > > > > >
> > > > > > Is there a workaround?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > >
> > > > > > Tobias
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe from this list, please visit:
> > > > > >
> > > > > >    http://xircles.codehaus.org/manage_email
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list, please visit:
> > > >
> > > >    http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email