WikiForum lacks anti-CSRF mechanism and is thus vulnerable to CSRF attacks. Creating categories, forums, threads, and replies are the specific functions affected. Category names, forum names, and descriptions are also not escaped and can therefore be exploited to inject maliciously crafted inputs due to the CSRF vulnerability.
Description
Details
- Risk Rating
- Medium
- Author Affiliation
- Wikimedia Communities
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| [SECURITY] Version 2.7.0 -- fix a whole bunch of CSRF and stored XSS issues | mediawiki/extensions/WikiForum | master | +754 -93 |
Related Objects
- Mentioned In
- T415379: Request to add Redmin to Security Team's Hall of Fame
T384156: Admin Permissions - Clicking "delete" doesn't ask for confirmation.
T347659: Write and send supplementary release announcement for extensions and skins with security patches (1.35.14/1.39.6/1.40.2/1.41.0)
T340874: Write and send supplementary release announcement for extensions and skins with security patches (1.35.12/1.39.5/1.40.1)
T333626: Write and send supplementary release announcement for extensions and skins with security patches (1.35.11/1.38.7/1.39.4/1.40.0)
T325849: Write and send supplementary release announcement for extensions and skins with security patches (1.35.10/1.38.6/1.39.3)
T318974: Write and send supplementary release announcement for extensions and skins with security patches (1.35.9/1.38.4/1.39.1)
T311785: Write and send supplementary release announcement for extensions and skins with security patches (1.35.8/1.37.5/1.38.3)
Event Timeline
cc @Universal_Omega for input
I took a quick look at tackling this with pretty much the most basic way possible. Some quick notes based on today's experiments:
- forumadmin-only "sort forum up/down" feature needs to be implemented differently, it's now just a GET request so it needs to have a <form> that POSTs for no-JS users and for JS users, an API module + appropriate amount of AJAX is in order
- ditto for the "make thread sticky"/"remove thread stickiness" feature
- somehow I seem to have broken the "submit a new topic" -> "immediately after submitting submit a reply using the form" feature while trying to tackle this bug
- gosh, it's 2022, almost 2023, and WF still lacks a preview button?! Darn. Even MediaWiki-extensions-Comments has one these days...
Attached is my WIP patch.
@ashley, if it helps then maybe XSS and CSRF for the functionalities using PHP could be patched first? Please let me know if I can help in any way.
Here's a patch I did back in late May to work towards fixing any and all issues reported here, in case if someone wants to give it a go.
(NB: It took me all too long to realize a bunch of XSS issues were also merged into this ticket, which I started as a CSRF ticket. IMO that should've been kept as a separate thing, since, well, they are separate issues, even if both are a type of security vulnerability.)
Anyway, the patch sacrifices some administrative functionality for no-JS users in favor of fixing the CSRF issues by using AJAX and the new API modules. I don't love it but it's an acceptable trade-off, because relatively few people have JS turned off in general and most of the functionality is still there even for no-JS users, it's just some very specific, advanced administrative tasks which defiintely aren't daily things which no longer can be done with JS off.
I haven't really played too much with this since late May or early June probably, and while I think I did manage to squish all the bugs, another set of eyes sure wouldn't hurt for the patch is literally over 1600 lines long...
Change #1108384 had a related patch set uploaded (by Jack Phoenix; author: Jack Phoenix):
[mediawiki/extensions/WikiForum@master] [SECURITY] Version 2.7.0 -- fix a whole bunch of CSRF and stored XSS issues
Change #1108384 merged by jenkins-bot:
[mediawiki/extensions/WikiForum@master] [SECURITY] Version 2.7.0 -- fix a whole bunch of CSRF and stored XSS issues