[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Mar 2014 00:21:37 +0100
From: Jann Horn <jann@...jh.net>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: MediaWiki 1.22.5 login csrf
On Fri, Mar 28, 2014 at 06:13:49PM +0000, Florent Daigniere wrote:
> > > > 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!
> > >
> >
> > I think I threw you off here-- this is just one reason why an attacker
> > might want to do this. It's tangential to the actual flaw we fixed.
>
> If mediawiki really allows users to define javascript that will be
> loaded on pages they visit, that's a vulnerability... There's no way to
> do that securely if the "content" and "application" data are served from
> the same FQDN.
MediaWiki allows users to define Javascript that will be loaded on pages they
visit, *but only for themselves*. If I can inject JS into the pages I view,
that is not a vuln, just like it isn't a vuln that a user can execute JS in
the context of any website by pasting it into a debug console in his browser.
However, this means that Login CSRF becomes a big security issue because it
would allow me to add evil JS to my account and then force the browser of
someone else to execute it in the context of the MediaWiki server's domain.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
