User:CSteipp (WMF)/ISec Audit

= Setup =

Vagrant

 * Setup vagrant
 * Use 1024M memory
 * Enable roles: centralauth visualeditor pdfhandler svg parserfunctions checkuser echo flow multimediaviewer proofreadpage timedmediahandler
 * Add checkuser group to Admin user
 * Add to a file "tiffhandling.php" in settings.d/

Image
(download link)

= Priorities =
 * 1) Upload, processing, and display of images/files (especially the handling of more obscure formats like svg, and Pdf/DjVu)
 * 2) * By default, MediaWiki handles png, jpg, and gif files. The upload handling is in includes/upload/, and the handling of parsing and converting different formats is handled by code in includes/media/. The vagrant roles above add extensions and some config flags to setup file handling very similar to WMF sites:
 * 3) ** timedmediahandler (ogg, ogv, oga, flac, wav, webm) - Add extensions MwEmbedSupport and TimedMediaHandler. Converts files using ffmpeg, and displays them using a variety of techniques.
 * 4) ** svg (svg) - enable core's SVG processing. Uses rsvg, which is what the WMF uses in production.
 * 5) ** proofreadpage (djvu) - enables core's DjVu processing, which relies on ddjvu, djvudump, djvutext, etc.
 * 6) ** pdfhandler (pdf) - Adds extension PdfHandler. Processing is almost identical to core's djvu handling, but uses ghostscript and imagemagick for processing
 * 7) ** settings.d/tiffhandling.php (tiff) - enable core's tiff handling
 * 8) Our wikitext -> html parsing in general
 * 9) * Allowing users to edit wikitext and display their edits as html is probably the most basic feature of MediaWiki. The code is mostly in includes/parser/. We assume that any possible wikitext, when parsed to html, is safe from:
 * 10) *# executing javascript
 * 11) *# loading external resources that could be used to track readers
 * 12) * The functionality of the parser can be extended with parser functions, allowing editors to use html-like syntax that calls extension code to process the input. In the vagrant config, the parserfunctions role with adds ParserFunctions. We distribute the ParserFunctions extension with the basic MediaWiki tarball, so those functions should be carefully looked at as well.
 * 13) * If time allows (probably after Mediaviewer is done), assessing the lua template engine (Scribunto extension) would also be helpful. It returns wikitext which is parsed to html, but we would like to make sure the lua engine (luasandbox) can't be used to attack the host.
 * 14) VisualEditor extension
 * 15) * This is the wysiwyg editor written by the WMF. It delivers a javascript editor for the user to edit the article text (in html), then translates the final html back into wikitext using the parsoid node.js service. The wikitext is then saved in a normal fashion, and users see the html that was parsed from the saved wikitext.
 * 16) * It would be most helpful for this portion of the assessment to focus on the javascript editor and the parsoid service, since wikitext->html parsing is covered in #2.
 * 17) CentralAuth extension (our authentication and single sign-on extension)
 * 18) * Initially, the WMF added new wikis without
 * 19) * Focus on password, session management, single sign-on and autologin protocols
 * 20) CheckUser extension (the extension that handles all of the User<->IP mapping, which we use for spam investigations mostly)
 * 21) Mediaviewer
 * 22) Echo extension
 * 23) Flow extension

In the audit, we're hoping to cover 1-5. Others extensions will be audited as time allows.

= Security Properties = See Security_for_developers/Architecture for a list of security properties and objectives for MediaWiki.

For this assessment, we're less interested in failures in spam/vandalism mitigation and DoS attacks in general. Although WMF sites get a constant stream of DoS attacks and spam, we're able to mitigate them to an acceptable level with small config changes and volunteer effort.

Also note that we've specifically decided not to protect a few things:
 * For a default wiki install, we do not attempt to protect the user names of site users. The list of all username is available at Special:ListUsers, and the edit history and Special:Log show the usernames of users who edited or created accounts. Private wikis can restrict access to all but a few pages to prevent usernames from being displayed, and when possible MediaWiki will attempt to support wikis that wish to keep these private. However, this is not guaranteed, and shouldn't be counted on by private wikis.
 * Except on private wikis, all content is assumed to be publicly accessible. See also Security_issues_with_authorization_extensions.

= Background =
 * A good, although slightly dated description of MediaWiki's architecture: . That should help the auditors understand core vs extensions, and how some of the major components are put together.