[pLog-svn] xss in 1.2.7

[Matt Wood]

I'll see if I can dig up that link.

On Tue, May 6, 2008 at 10:38 AM, Mark Wu <markplace at gmail.com> wrote:

> Using state machines, it quite interesting, can you show us the link?
> Thanks!!
>
> Mark
>
> 2008/5/6 Matt Wood <matt at woodzy.com>:
>
> I guess user specific implies authentication, but the authentication but
> > makes sure that no random dude can retrieve a valid nonce. So, yes the
> > current login does that.
> >
> > By being page & form specific you gain alot. By tying the nonce that
> > closely to the form/page then you are making sure that the only way to
> > retrieve the correct nonce is through a valid request to that page/form. If
> > the nonce is site-wide and valid on any form within the page, then all you
> > need is a mistake in the way you validate the nonce and someone can retrieve
> > a valid nonce.
> >
> > I've seen this ALOT with login pages on sites using site-wide nonces,
> > the first request to the login page will not have a nonce. Good you don't
> > want to reveal it. But if you made that same request with invalid
> > credentials then the nonce is exposed on the response asking you to try
> > again.
> >
> > A site-wide nonce does little more than a simple authentication does,
> > there is generally a way to get a valid nonce. Think about it, your
> > basically just adding a little extra information to the session in the get
> > or post parameters... why not just force the session id into the url? Well
> > then you leak the session id via the referrer. Same for nonces.
> >
> > One of the more clever implementations of a site-wide crsf protection I
> > have seen uses a state machine (with your current state in the session) to
> > protect against out of band requests to random pages.
> >
> >
> > On Tue, May 6, 2008 at 10:04 AM, Jon Daley <plogworld at jon.limedaley.com>
> > wrote:
> >
> > >        What do you gain by being form or page specific?  And what does
> > > "requires authentication" mean?  something more than a regular login that we
> > > already have?
> > >        I was thinking of a simple user and time token.
> > >
> > >
> > > On Tue, 6 May 2008, Matt Wood wrote:
> > >
> > >  It depends on how you implemented the nonce.
> > > >
> > > > I really haven't look into this specific vuln, I've just happened on
> > > > the
> > > > emails you guys were sending around... but assuming you have
> > > > implemented a
> > > > site-wide nonce implementation that is page specific, form specific,
> > > > user
> > > > specific, uses timed expiration, and requires authentication... it
> > > > would be
> > > > hard to utilize the reflection attack in any meaningful way other
> > > > than
> > > > attack yourself.
> > > >
> > > > I would never assume that it would be impossible, most of the time
> > > > it is the
> > > > conglomeration of vulnerabilities that allow an attack to do
> > > > meaningful
> > > > things.
> > > >
> > > > -Matt
> > > >
> > > > On Tue, May 6, 2008 at 3:17 AM, Reto Hugi <plog at hugi.to> wrote:
> > > >
> > > >  Jon Daley wrote:
> > > > >
> > > > >    I must really not be getting XSS then.  If every post has to
> > > > > > have a
> > > > > > token on it, how would someone guess the token in order to have
> > > > > > the
> > > > > > javascript be accepted and displayed on the screen at all?  I'd
> > > > > > expect the
> > > > > > token to be checked first, and simply die() if it doesn't match.
> > > > > >   I can't figure out a scenario where an attacker would be able
> > > > > > to get
> > > > > > javascript displayed on the screen to be executed within the
> > > > > > context of that
> > > > > > domain to steal a cookie, or do anything.
> > > > > >
> > > > > >
> > > > > >  Jon, you're right on that very example. But I suppose we won't
> > > > > implement
> > > > > the CSRF Check (i.e. the nonce check) on every request, but only
> > > > > on the
> > > > > ones writing to the database (that's where CSRF is the most
> > > > > dangerous).
> > > > > And therefore we still need to make sure we are not vulnerable to
> > > > > xss.
> > > > >
> > > > > it was probably good to have this discussed once again. it's the
> > > > > only
> > > > > way we all get the same understanding of those attacks :)
> > > > >
> > > > > @matt: or do you see a possibility of exploiting our xss vuln.
> > > > > *if* we
> > > > > had implemented the nonce on every request (that's the scenario
> > > > > jon is
> > > > > thinking about...)
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > pLog-svn mailing list
> > > > > pLog-svn at devel.lifetype.net
> > > > > http://limedaley.com/mailman/listinfo/plog-svn
> > > > >
> > > > >
> > > >
> > > --
> > > Jon Daley
> > > http://jon.limedaley.com/
> > >
> > > The only joy in the world is to begin.
> > > -- Cesare Pavese
> > >
> > > _______________________________________________
> > > pLog-svn mailing list
> > > pLog-svn at devel.lifetype.net
> > > http://limedaley.com/mailman/listinfo/plog-svn
> > >
> >
> >
> > _______________________________________________
> > pLog-svn mailing list
> > pLog-svn at devel.lifetype.net
> > http://limedaley.com/mailman/listinfo/plog-svn
> >
>
>
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://limedaley.com/pipermail/plog-svn/attachments/20080506/3a12c628/attachment.htm>