On Wed, Sep 16, 2009 at 11:29 AM, Anthony <wikimail(a)inbox.org> wrote:
The only one I can think of that I know of directly
would be the IP spoofing
one where the attacker pretended to be a proxy and sent a false "IP
forwarded" or whatever.
That shouldn't work if MediaWiki is configured with a correct list of
trusted proxies.
But indirectly I know of many "Grawp"
exploits. I guess I know of one of
those directly, which is whatever I got hit with on my Mediawiki
installation. I never investigated what specifically it was, though.
What were the consequences?
There's also various forms of nasty
once-upon-a-time unrecoverable vandalism
like moving a page on top of another which arguably aren't security holes
but arguably *are* security holes in the form of design flaws.
You can become admin via XSS (or password guessing, MITM, etc.), and
move a page over a deleted page, where both have lots of history, then
undelete. But 1) that's only really a problem on wikis large enough
to have huge histories; 2) it's still reversible, just requires a lot
of tedious manual effort or maybe some carefully written queries; and
3) if you can't be bothered to reverse it, you could just copy out the
couple hundred most recent revisions and leave the others mixed
together, it's not really critical that the old ones are still
missing. So it's not a huge deal. There are probably some DOSes you
can do as an admin as well; and you could inject arbitrary JavaScript
on all page views.
But this is all pretty easy to detect and not terribly hard to
reverse. The JS injection is potentially the most damaging, but if
the wiki is on its own domain, the worst you could do is stealing some
IP addresses, and phishing. Compare to most web software, where if
you become admin you can at *least* irrecoverably delete the whole
site in a few clicks, and possibly run arbitrary code on the server --
and in the latter case you can almost certainly cover your tracks
pretty well, too. So I think we're not doing too badly.