Manual:画像認証
この記事では、管理者が利用者権限に基づき画像やファイルへのアクセスを制限するための方法を示します。
サーバーにアップロードされたファイルは、通常MediaWikiを通さずに直接ウェブサーバーから公開されます。 パスの暗号化(例:/c/c4/...)を最低限のセキュリティとして用いることはできますが、それらのパスはファイル名から簡単に計算できるので、この方法は本質的な保護にはなり得ません。
この設定は推奨されていません。 MediaWikiはコンテンツ管理システム(CMS)としては設計されておらず、それゆえ秘匿性の高いデータを保護できる仕様ではありません。 (むしろ、可能な限りオープンであるように設計されています。) このため、プライベートな項目についても、機能の揃った完全な保護はそもそもサポートされていません。 管理者がこの機能を使用しようと考えている場合、Security issues with authorization extensions をよく読んでください。
概要
既定では、すべてのアップロードされた画像(とファイル)はWebサーバーから直接アクセス可能です。 MediaWiki のフレームワーク内で許可された利用者のみにアクセスを許可したい場合、2 つの条件を満たす必要があります:
- 実際のディレクトリは直接のアクセスから保護され;
- MediaWikiの認証はそのディレクトリを含むURLが要求されたときにスクリプトの実行によって画像/ファイルへのアクセスがあったときに呼び出される必要があります。
基本的な実装には次の設定が必要です:
- アップロードディレクトリ($wgUploadDirectory )を、ファイルシステム上のWebルートディレクトリの外にするか、保護します。
- アップロードパス($wgUploadPath )をimg_auth.php へのパスに設定します。
両方のメカニズムはWebサーバープラットフォームによって異なります。 ここでは2つのプラットフォームについて詳細な手順を説明します。
- Apache (ほとんどのバージョン)
- Microsoft Internet Information Server (IIS), version 6.0 以降
すべての説明において、MediaWiki が "/path/to" にインストールされているとします。
例えば:
http://wiki.example.org/MyWiki
"/path/to" は "/MyWiki"です。
"img_auth.php"はどのように機能するか
Image authorization works by routing requests for uploaded media files through the img_auth.php script, instead of allowing the webserver to send the file to the browser directly.
This is done by setting $wgUploadPath to the location of the img_auth.php script ($wgUploadPath = "$wgScriptPath/img_auth.php";
), instead of the upload diectory.
This causes MediaWiki to generate file URLs that look something like http://wiki.example.org/w/img_auth.php/01/01/Example.png
.
When the web server receives a request for such a URL, it will know to call the img_auth.php
script and pass it the remainder of the URL as PATH_INFO.
The script will then check whether the user has access to the file given in the PATH_INFO, based on the normal mechanism used for managing access to wiki pages.
If img_auth.php determines that the user has access to the requested file, it reads the file's content and streams it back to the user, just as if the web server was serving the file directly from the disk.
If, however, the user does not have access to the file, img_auth.php returns the standard 403 "Access Denied" error.
Configuring File Uploads
Before attempting this configuration it is very important you understand how to configure file uploads. Please take a few moments to review and understand this article - it will save you a lot of time.
PHP PATH_INFO Support
This requires that your PHP setup support PATH_INFO (many CGI configurations do not) and you need to be in $wgWhitelistRead mode or else, there wouldn't be a point ... unless you just like a more secure MW install. See below.
Another Scenario, Security Motivated (Apache/Unix ONLY)
Even if you don't want to restrict access to your images you might want to make use of the img_auth.php
mechanism: to avoid publicly accessible directories, where the web server has write permissions.
Though a web server writable directory is not insecure in itself, it is the first half of a successful attack to your web server.
The second half then would be some exploitable (php) script, being MW or, most likely, some other script.
If the attacker can exploit the broken script to upload or generate another script intended to help him with further attacks/spamming etc, the attacker still needs a place to store that script in, writable by the web server ... and has it available and well known in the images
directory of MW standard installations.
A very first security measure against this will be to place a .htaccess
file inside the images
directory with this content:
# No php execution in the upload area
php_admin_flag engine off
And that .htaccess
must not be writable by the web server! It is a pity, that MW doesn't come with this by default (at least not in 1.6.10).
But even better will be to also move the web server writable images
directory outside of the document root, renaming it to something unguessable (e.g. the MD5 hash of <whatever>) and streaming the images via img_auth.php
, so that the real directory name never ever shows up.
To accomplish that follow these steps:
- login in to a shell of your web server (similar actions are often possible with your FTP client, if not, ask your provider to assist you)
- create the unguessable
images/upload
directory outside of (in parallel to) your document root (note the/..
at the end of the path):cd </absolute/path/to/your/doc_root>/.. mkdir <推測できないディレクトリ名>
- make it read/writeable for the web server:
chgrp <your_web_server_group> <推測できないディレクトリ名> chmod 770 <推測できないディレクトリ名>
- create the .htaccess file as noted above and make it readable only (this is paranoia, because the web server never looks here, only PHP not taking care of
.ht*
files normally, but just in case this directory ever will be made available to the web server directly):cd <推測できないディレクトリ名> echo 'php_admin_flag engine off' > .htaccess chmod 444 .htaccess
- change your LocalSettings.php config file:
$wgUploadPath = "$wgScriptPath /img_auth.php"; $wgUploadDirectory = '</absolute/path/to/your/doc_root>/../<推測できないディレクトリ名>'; $wgEnableUploads = true; # We don't wanna restrict access, just make our MW install more secure $wgWhitelistRead = false;
which should do the right thing without any additional configuration.
That should do the job for web servers with PHP running as an Apache module.
No further Apache config file changes are necessary.
You then will never see the path to your images, img_auth.php
intercepts all read accesses.
But all of your images are served, including thumbs.
If you use CGI or IIS your milage may vary.
Apache Instructions
Apache Step 1. Protect Images Directory from Internet Access
In your [/path/to]/images directory, create an .htaccess containing one line:
Deny from All
Apache Step 2. Execute Script img_auth.php
for all Accesses
Apache Step 2.1. Change $wgUploadPath in LocalSettings.php
. This is not needed if Apache step 2.2 is done.
$wgUploadPath = "[/path/to]/img_auth.php";
[/path/to]
is the URL path, not the file system path, so if img_auth.php is in /usr/share/mediawiki
but is accessed as http://example.org/mediawiki/img_auth.php
, the line would read:
$wgUploadPath = "/mediawiki/img_auth.php";
Be sure to add a leading slash /
if img_auth.php
is actually in your root-directory.
Images won't be displayed at all if you forget to do so:
$wgUploadPath = "/img_auth.php";
Apache Step 2.2. Create aliases to execute img_auth.php
Edit the httpd.conf
file and add the two following aliases:
Alias [/path/to]/images/ [/path/to]/img_auth.php/
Alias [/path/to]/images [/path/to]/img_auth.php
The second [/path/to] on each line should be the absolute path on the file system, and it may be necessary to add a trailing frontslash to img_auth.php (i.e., use [/path/to]/img_auth.php/).
Apache Step 2.3. Restart your Apache server
Apache Instructions without PATH_INFO with mod_rewrite
Apache Step 1. Download the cgi-supporting image authorization script
When PATH_INFO is not available download the CGI-supporting image authorization script.
Save script under the name cgi_img_auth.php
in your MediaWiki directory.
Apache Step 2. Protect Images Directory from Internet Access
In your [/path/to]/images
directory, create an .htaccess
containing one line:
Deny from All
Apache Step 3. Execute Script cgi_img_auth.php for all Accesses
Apache Step 3.1. Change $wgUploadPath in LocalSettings.php
$wgUploadPath = "[/path/to]/cgi_img_auth.php";
Apache Step 3.2. Edit .htaccess
Edit the .htaccess to look like this
RewriteEngine on
RewriteRule ^/path/to/images(.*)$ /path/to/cgi_img_auth.php/$1 [R]
RewriteRule ^path/to/cgi_img_auth.php/(.*)$ path/to/cgi_img_auth.php?path=/$1
Note, however, this step is unnecessary on some installations.
Apache - Compatibilize with clean URLs
If your website is rewriting URLs through .htaccess
, then you will need an exception before the custom rewrites:
RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]
(This means: in case of img_auth called, stop rules)
Example of .htaccess:
RewriteEngine On
# First condition&rule:
RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]
# Rest of rules:
RewriteCond ...
RewriteRule ...
Apache - Deny the directory list
If you don't want user to list your images folder set this up on your Apache configuration:
<Directory /var/www/wiki/images>
Options -Indexes
</Directory>
IIS Instructions
Implementation in IIS is more complex because it lacks the inherent 'pipe' capabilities of Apache or Unix in general. However using a few tricks, IIS can be made to execute the CGI and achieve protection.
IIS Step 1. Protect Images Directory from Anonymous Internet Access
With IIS it is important that users cannot access images or files by using alternative URL paths to the bypass the virtual directory redirect. Therefore, a new directory outside the MediaWiki root must be created.
IIS Step 1.1 Create New Physical Directory
Create a new physical directory. This directory should not be inside any other existing web directories or virtual web directories:
例:
c:\inetpub\wwwroot\MyWikiImg
IIS Step 1.2 Check/Set Directory Security
The Directory security must allow read, write, modify for the Internet Guest Account (usually IUSR_[server name]). Don't worry, you're going to regulate this in subsequent steps.
IIS Step 2. Execute Script img_auth.php for all Accesses to Image Directory
In IIS this is done by creating a virtual directory with the same name as the physical directory (if your directory is off the root web).
IIS Step 2.1 Create Virtual Directory with Same Name as Physical Directory
Create a new virtual directory using Start->Administrative Tools->Internet Information Services (IIS) Manager in the web service you are using for MediaWiki.
Right click on the web service->New Virtual Directory...
In the wizard, create a new virtual directory with the same name as the physical directory and point it to that directory.
IIS Step 2.2 Redirect New Virtual Directory to img_auth.php
Still in IIS Manager, right click on the new virtual directory->Properties select the 'Virtual Directory' tab and change the 'The content for this resource should come from:' to 'A redirection to a URL'. Fill in the 'Redirect To:' with the URL to img_auth in your MediaWiki.
例:
http://wiki.example.org/MyWiki/img_auth.php
Remember to Click Apply!
IIS Step 3 Copy Old Image Directory to New
Copy the contents of the old images directory ($ip/image) and subdirectories into the new directory you created.
Note: The image
directory will not exist in the new directory.
The new directory should not appear as:
Wrong:
MyWikiImg images 0 1 . . .
Right:
MyWikiImg 0 1 . . .
IIS Step 4 Redirect MediaWiki Images Processing
IIS Step 4.1 Change $wgUploadPath in LocalSettings.php
$wgUploadPath = "[NewVirtualDirPath]";
例:
$wgUploadPath = "/MyWikiImg";
IIS Step 4.2 Change $wgUploadDirectory in LocalSettings.php
$wgUploadDirectory = "[NewVirtualDirImages]";
例:
$wgUploadDirectory = "D:\Inetpub\wwwroot\MyWikiImg";
IIS Step 4.3 Restart your IIS Web Service
IIS Step 4.4 Troubleshoot IIS PATH_INFO
If your installation is not working, it may be because img_auth.php requires the server to return PATH_INFO to know exactly which file you wish to access (e.g., everything in the URL after the virtual directory).
There have been several articles and hints that some versions of IIS may disallow the server variables PATH_INFO and PATH_TRANSLATE 'for security reasons'. While we did not have this problem on the current server and patch level (IIS 6.0) it is a noted issue for IIS 4.0 (and possibly prior), you may want to investigate if img_auth.php is not working for you.
The full knowledgebase article may be found at Using PATH_INFO and PATH_TRANSLATED from CGI Applications. The article instructs you on how to run a program written in MS Visual Basic (you may need to load CScript).