Question - is there a way to enable session persistence so that if a user logs in then changes IP they are logged out agaim?
184.108.40.206 14:49, 12 March 2009 (UTC)
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)
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. --220.127.116.11 04:42, 15 May 2005 (UTC)
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....
18.104.22.168 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
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
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)
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)
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.
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. --22.214.171.124 20:12, 10 Feb 2005 (UTC)
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.
- 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)
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:
Deny from all
If the above step is not done, the user can simply substitute
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.firstname.lastname@example.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)
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)
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?
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)
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.