Manual talk:Security

Session Persistence

Question - is there a way to enable session persistence so that if a user logs in then changes IP they are logged out agaim? 217.155.13.201 14:49, 12 March 2009 (UTC)

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Question - I've been playing around with starting a Wiki with Wikimedia, but I'm only moderately knowledgable in these matters; furthermore, the site is managed through a hosted server, so I don't know if I have any say over Apache settings. Can some of this be rendered a little more applicable for similar situations? And can it also be made a little more dummy-friendly? Thanks.

Yeah it would be useful to keep this page applicable to users using shared/virtual hosting environments. These may not support huge wikis, but would be suitable for some small group collaborations. And perhaps some of the repitition from this page could be removed. -- SimonEast 05:34, 4 Aug 2004 (UTC)

javascript attacks

You may wish to serve HTML pages as plaintext to prevent cookie-stealing JavaScript attacks.

Huh. Won't this break a lot of things? Or does this apply only to the upload directory (as the code might suggest)? And doesn't Microsoft's browser treat URLs ending in .htm as web pages anyway? An example of the attack might clarify what is going on here. --Nealmcb 02:50, 26 Jul 2004 (UTC)

It only applies to the images directory and I believe that Internet Explorer will ignore the text/plain MIME type for documents using HTML-like tags. --144.136.172.13 04:42, 15 May 2005 (UTC)

User accounts

It would be nice to have some indication on how to disable user account creation or at least to prevent people from doing so from outside of a certain domain. For now it seems that all this security stuff is useless and that there is a big Hack here written on the accounts creation page.

--Osyluth 04:39, 2 Aug 2004 (UTC) Cross-site Scripting Attack Cross-site scripting ('XSS' or 'CSS') is an attack that takes advantage of a Web site vulnerability in which the site displays content that includes un-sanitized user-provided data. For example, an attacker might place a hyperlink with an embedded malicious script into an online discussion forum. That purpose of the malicious script is to attack other forum users who happen to select the hyperlink. For example it could copy user cookies and then send those cookies to the attacker. Insert non-formatted text here

---

I've been getting hacked/anoyed by a user who as soon as I block he creates a new user account with a spam protector e-mail address (@spam.la for instance), confirms himself, the wreaks havoc on my wiki. Can I somehow prevent a particular domain from being able to confirm users? It has been keeping me up at night as he is usually active when I should be going to bed....

Thanks,
24.127.37.76 05:46, 16 February 2007 (UTC)

Alternative to suggested security settings

This is just a comment, these settings are not yet confirmed to be secure!

The security documentation suggest two things: for the upload directory, turn of php with the php_admin_flag engine off. However, this turns off php for the whole site (tested on Apache2, PHP 4.3 and Windows 2000). An alternative might be

 RemoveType .php

Second, setting the MIME-type to text/plain for .html files will not prevent Internet Explorer 4 and upwards from displaying the file as html, because the browser will override serverprovided MIME-types if it can determine the MIME-type by analysing the file.

Allowed filetypes for upload??

I'd like to modify my wiki so that users can upload a variety of document formats such as PDF, DOC, XLS and the like and have them displayed as icons inline in the text. I tried manually putting a .ppt file in the /images directory, then creating a link that looked like

[[media:myfile.ppt|My Power Point]]

but the URL came out looking like

http://mywiki.tld/wiki/images/3/3b/myfile.ppt

When I tried the Special:Upload page, it gave me a "Warning" that .ppt was not a recommended file format. Evidently the recommendation was final, as I was never able to complete the upload.

So I guess my question is, how do I add alternative upload filetypes to the list of allowed ones? Also, what's the logic behind the directory structure for a media: link? It seems to have arbitrarily created the /3/3b directory structure, though I doubt it's as arbitrary as it seems.

You can add the line "$wgStrictFileExtensions = false;" in your LocalSettings.php to allow overriding of the warning. --H. J. Hill 14:23, 1 Feb 2005 (UTC)

I have tried the above "$wgStrictFileExtensions = false;" but not only does it not work, it breaks the ability to upload .jpg .gif and .png files. There must be some way to modify the whitelist to include .pdf, .doc, .xls etc... --S. G. Porter 12:00, 15 Jul 2005 (EDT)

Just a guess, but the 3/3b/ extension is probably to avoid having too many files in one folder, as that causes some other utilities to not work quite right in e.g. Linux once a certain number of files is reached. Just another guess, your file might have been named '3bwhatever.ppt', which is where the /3/3b/ came from?

..or it could be the first two letters of the hashed name.

You might consider checking this page. It might be what you are looking for.

Updated upload directory

The new name for the mediawiki upload directory is "/images", isn't it? I corrected the examples to reflect this name, I thought that was less confusing. If people know this was the correct thing to do, please delete this notice. Thanks. Chira 06:44, 28 Oct 2004 (UTC)

Issues related to the MediaWiki scripts

This section contains

Earlier versions of MediaWiki included a bug that potentially allows logged- in users to delete arbitrary files in directories writable by the web server user by manually feeding false form data; this is now fixed.

but that doesn't give me any idea if I use a "earlier" or "later" version? To paraphrase: in which version was that fixed? --H. J. Hill 14:23, 1 Feb 2005 (UTC)

Repeated text

The text mentions and gives examples of securing the upload directory three times: First under "General Security Considerations" as <Location "/wiki/images">, then under "Issues related to the Apache httpd web server" as <Directory "/Library/MediaWiki/web/images"> and finally under "Securing the upload directory" as <Location "/wiki/images"> again. Only one of these recommends AllowOverride None.

text/plain?

The configuration fragment for the upload directory shows text/plain for .html, .html, etc etc. While I certainly agree that script execution should be *off* for that directory, I'm not convinced that text/plain is ever the right type for those files, barring perhaps .php. --64.180.165.76 20:12, 10 Feb 2005 (UTC)

text/plain is used to prevent javascript that might be embedded in the uploaded pages from running in the clients browser, and sending their Wiki cookies/password to some other site. 24.5.15.101 21:58, 15 Apr 2005 (UTC)

Confidence

These discussion comments don't give me a lot of confidence that the securtity issues have been thought through!

It also would help me if the examples made it clear what is fixed text, and what is not. For example, there is a reference to directory /Library/MediaWiki/web/images, which I cannot find on my system. I don't know enough about MW yet to tell if it has a different name on my system or if Apache has redirected it or what. Of course I should learn more about MW etc and then stop asking damnfool questions, but in order to learn, I need to set the thing up so I can play with it. Catch-22. It might be fair to expect most readers of this section to be newbies.

In short, please explain the examples so I can understand what they are trying to do, and how they are trying to do it, so I can then adapt them to my own circumstances. This needn't be a long explanation - no need to rewrite the Apache docs. Just a pointer in the right direction.

Thanks!

--Norman Paterson

This page is pretty haphazard and not entirely up to date or accurate. I'll write up some new recommendations. --brion 22:52, 14 Jun 2005 (UTC)

I mostly rewrote it. There's still more to say, potentially, but hopefully it's now clearer what it's meant to be about. --brion 00:36, 15 Jun 2005 (UTC)

Download Security

What about download security? I have a private wiki, login required, and everything in the uploads/images directory, all files, are browseable and downloadable via apache? I've disabled indexing in apache but files are still directly downloadable. Is there anyway to prevent this without using htaccess?--Zebathon 18:28, 8 December 2005 (UTC)

Maybe you could try to use the img_auth.php under wiki's main directory, however, I can't get it work.

I've tried to use img_auth.php, according to the comment in it, it state:

To use, in LocalSettings.php set $wgUploadDirectory to point to a non-public
directory, and $wgUploadPath to point to this file. Also set $wgWhitelistRead
to an array of pages you want everyone to be able to access. Your server must
support PATH_INFO, CGI-based configurations generally don't. 

so I set my LocalSettings.php as following

$wgUploadPath       = "$wgScriptPath/img_auth.php";
$wgUploadDirectory  = "$IP/images";

but it doesn't work, all my images in Wiki become not viewable because of the wrong path, is there something I did wrong? and what exactly is PATH_INFO support? I'm suing Apache 2.2 under Windows XP. Could someone give the example on how to use img_auth.php, much appreciated!

Maybe you could try it out and if it work please share your method here! Qt5

After I set the $wgUploadPath to point to this file, the image path becaome "http://www.myserv.com/wiki/img_auth.php/6/6f/e/image.png", and it looks like the img_auth.php script just don't run at all and instead the browser look for the directory "img_auth.php" which of cause doesn't exist. Is there anything I did wrong? do I have to do anything in http.config to turn the PATH_INFO on and if so how to do that?

See http://httpd.apache.org/docs/2.0/mod/core.html but the default worked for me. (I was able to follow the above description and get it to work without modifying httpd.conf.)--Jbrusey 00:37, 23 May 2006 (UTC)

Also note the need to stop Apache directly serving files in $wgUploadDirectory (if for example, you leave it as $IP/images). To do this under FC4, I added a file called /etc/httpd/conf.d/wiki.conf with the following content:

<Directory "/var/www/html/wiki/images">
    AllowOverride None
    Order allow,deny
    Deny from all
</Directory>

If the above step is not done, the user can simply substitute images for img_auth.php in the URL to bypass the security controls.--Jbrusey 00:37, 23 May 2006 (UTC)

Problems with PNG Upload

I installed MediaWiki 1.5.6 and now image upload does not work. Error message is " file corrupted ..." . I found out, that it has homething to do with mime. When I set $wgVerifyMimeType = false; in the LocalSettings.php I can upload the image but I can not see the image since mediawiki sets the mimetype to plain/text When I click at the imagelink I see a warning that the file can contain malicious code. Hope somebody can help.

I'm having the same problem with a fresh install of 1.5.8 under FC4. JPEG displayed correctly, but PNG uploads end up with MIME type: text/plain and won't display inline. MediaWiki generates an href construct instead of an img construct. I've noted that my /etc/httpd/conf/magic has no entry for PNG, but does have entries for GIF, JPEG, and TIFF. MaxEnt 14:26, 21 April 2006 (UTC)

Working solution for Motorstreak's FC4 box. Also worked on Xiandos FC5 box (solving same uploaded PNG files problem, MediaWiki claimed most PNG files were "corrupted" after upgrade to 1.6.x):

Add this to /etc/httpd/conf/magic (You might also require an httpd restart.)

# PNG images
0       string          \211PNG         image/png

Refer to http://mail-archives.apache.org/mod_mbox/httpd-bugs/200311.mbox/%3C20031107191058.8938.qmail@nagoya.betaversion.org%3E for a detailed description of the magic file fix for Apache. --Motorstreak 19:11, 21 May 2006 (UTC)

Previous PNG uploads retained the bogus MIME type text/plain, but new PNG uploads after the restart worked properly. The default magic file on my FC4 box is horrid. There are internal comments, but no version number, date, or upstream source is identified. Edits are commented with three letter initials. I'm somewhat shocked that such a shoddy and incomplete file forms part of the standard FC4 installation. MaxEnt 15:09, 21 April 2006 (UTC)

There are two different problems - how PHP identify uploaded file (and what MIME type is then saved to the database) and how Apache indetify MIME types when sending images to the client. We need just fix PHP. By default, PHP is using /etc/httpd/conf/magic file like Apache does (this file is inside httpd package in RHEL and Fedora). But there is a better file in /usr/share/file/magic.mime (from package file). So you may want to change PHP configuration by placing this line to the [PHP] section of /etc/php.ini and then restart the Apache and then reupload the image into the Wiki. You may also want to point Apache to the same (better) file too by fixing MIMEMagicFile option for mod_mime_magic module in /etc/httpd/conf/httpd.conf. Milan Keršláger 10:34, 22 May 2007 (UTC)

 mime_magic.magicfile = "/usr/share/file/magic.mime"

Adding svg to whitelist

In the content page, it says:

The default configuration makes an attempt to limit the types of files which can be uploaded for safety: * By default, file extensions .png, .gif, and .jpg are whitelisted.

Where can I whitelist .svg type if my apache webserver already lists svg as a mime type. Harriska2 16:13, 16 February 2007 (UTC)

Allow_url_fopen

I updated my php.ini a while back with the following note:

; ON for SpamBlock out of Wikipedia  MD.
allow_url_fopen = On

I obviously did this for a reason and I seem to remember that it was essential for connecting to SpamBlock. That was under MW 1.6.3 - I'm not sure if it is required for the most recent version (I'm on 1.9.1 now and I haven't changed this setting). If it is required, a note to that effect might be useful in the PHP settings section of the page. Michael Daly 05:34, 27 February 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

Upload Security: php_admin_flag engine off

I just added php_admin_flag engine off to my .htaccess already in /images.
Result: Internal Error. Maybe because it's not in the Apache .conf-file. If it's because of this, I think there should also added the way over .htaccess with php_flag engine off
--Cembon . . (Talk | Contributions) 23:28, 6 September 2013 (UTC)

Alternate file layout

Exposing only one directory with relevant .php files is very important in preventing many security holes mentioned and not mentioned in the document. Without it any file that's mistakenly left somewhere gives information to an attacker. What is missing though is which .php files should be exposed for MediaWiki to work properly? As a preliminary test, it seems that index.php and load.php are needed, along with a soft link to the resources directory. Does that make sense?

Without php-cURL, disabling allow_url_fopen can break MW

If disabled and cURL isn't available to PHP, some actions (such as page edits) can fail with an "allow_url_fopen needs to be enabled for pure PHP http requests to work" error. Some web hosts might disable fopen and not provide cURL. For clarity, this should be noted in the General PHP Recommendations section. (related issue) -Oznogon (talk) 20:07, 25 June 2017 (UTC)

Remove suggestion about disabling register_globals

Under the section "General PHP recommendations", it is suggested to disable "register_globals". But as it says on http://php.net/manual/en/ini.core.php#ini.register-globals, this boolean is DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.

"AllowOverride None" disables .htaccess for images/temp and images/deleted.

...And if some other system subfolders inside images/* have .htaccess, it will be disabled too. Any ideas how to fix it? — Preceding unsigned comment added by 213.251.196.210 (talk • contribs)

You can define security directly on the main webserver configuration with <Directory> sections. Also, temp folder shouldn't be placed inside a folder accessible from the webserver. The deleted images directory can also be placed outside of the published folder too. --Ciencia Al Poder (talk) 10:27, 8 January 2020 (UTC)

I think that should be stated somewhere in the install document or on this page.

Good chance that ppl believe they apache is more secure as MW comes by default with htaccess file for certain folder but in fact most default apache config is set to:

AllowOverride None

tx TiloWiki (talk) 21:02, 7 August 2023 (UTC)

Folder 'extensions' has no '.htaccess' and open for all.

It look dangerous. I want try to disable access for all exept js, json and css. Can it break something? — Preceding unsigned comment added by 213.251.196.210 (talk • contribs)

In the past extensions used to contain entry points for ajax requests, and also assets (images, scripts). Most of them are now served by api.php and load.php. If running your wiki you don't see anything accessing the extensions directory in your access logs, you can safely deny access to it. --Ciencia Al Poder (talk) 10:28, 8 January 2020 (UTC)

Blacklisting unsupported file formats with .htaccess and Apache

I ended up preferring to protect the images folder this way:

# Block unsupported file extensions
RewriteCond %{REQUEST_URI} ^/images/.*
RewriteRule !\.(png|gif|jpg|jpeg|webp|ogg|ogv|oga|flac|opus|wav|webm|mp3|midi|mid|mpg|mpeg|mp4)$ - [F,NC]

Specific list of web-exposed files

In the section Set DocumentRoot to /dev/null, it says (emphasis mine)

A more secure option for the Apache Web Server is to set the DocumentRoot to an empty or non-existent directory, and then use Alias directives in the Apache configuration to expose only the scripts and directories that need to be web-accessible.

But which files actually need to be exposed? So far, I figured out:

• index.php obviously
• img_auth.php if it is used
• wherever the site's icons are located

But are there any other files that need to be exposed for proper functioning? The cache dir? Any parts of the extensions? The remaining root-level PHP files such as api.php and rest.php or are those only strictly necessary if I want to expose the API to the end users? How about thumb.php, thumb_handler.php, autoload.php, load.php and opensearch_desc.php?

MrArsGravis (talk) 12:32, 7 June 2023 (UTC)