Re: Trails Security unsecure ???

> On Mon, May 26, 2008 at 1:00 PM, Tobias Marx <superoverdrive@...>
> 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@...>
> > > An: users@...
> > > 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@...>
> > > 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@...>
> > > > > An: users@...
> > > > > 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@...>
> > > > > 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
> >
> >
> >