Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Mar 2014 15:56:12 +0000
From: Florent Daigniere <florent.daigniere@...stmatta.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: MediaWiki 1.22.5 login csrf

On Fri, 2014-03-28 at 08:33 -0700, Chris Steipp wrote:
> On Mar 28, 2014 7:54 AM, "Florent Daigniere" <
> florent.daigniere@...stmatta.com> wrote:
> >
> > Sorry to be thick here but it still doesn't make any sense to me...
> >
> > The session-id should be renewed upon login AND any credential/privilege
> > change (that includes password changes). This protects against session
> > fixation attacks (where the attacker coerce a user into using a session
> > he controls).
> >
> > On these pages, there's usually no need for anti-CSRF protection as they
> > tend to require credentials (something the attacker, by definition,
> > doesn't have).
> 
> Slightly different attack. The attacker (who knows their own password and
> chooses the reset-to password) was able to cause a logged out user (victim)
> to login with the attacker's account via the change password form.
> 

That is the textbook example of a session-fixation attack. The "end
state" is that the victim uses a session the attacker can control.

> This attack is somewhat specific to mediawiki since we allow users to
> define JavaScript that will be loaded on pages they visit while logged
> in... So the victim in this case would run the attacker's personal
> JavaScript.
> 

It still doesn't make sense. Anti-CSRF tokens are only useful if the
"malicious script" is not running with the same origin!

Florent

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ