Manual:Security/ja

'''このガイドは未完であるが、サーバのセキュリティを強化したい管理者がいる場所への紹介を提供する. --brion 00:34, 15 Jun 2005 (UTC)'''

webサーバの構成と大きなサーバを動かしている人々に対してここにあるいくつかの助言は連動する. もしも、それらのいくつかに失敗したとしても、心配することはない!一般的な中尉事項は全てに適用する.


 * もしも、MediaWikiまたはWikimediaのwebサイト中でセキュリティ問題を発見したと信じるならば、security&#64;wikimedia.orgに直接コンタクトを取ってほしい. そうすれば、バグフィックスリリースを準備できる. 

最新のものにする
やらなければならない、ほとんどの重要なセキュリティステップは、ソフトウェアを最新にすることである. MediaWikiとそれに従属するソフトウェアの両方は、あなたに影響するであろう、新しく発見されたセキュリティの脆弱性を収集する新しいバージョンを時折作成する.

MediaWikiを動かしている誰でもmediawiki-announce mailing listを購読することを強く推奨する. これは、新しいバージョンのアナウンスのみの、非常に流量の少ないMLである.

現時点(2006年10月)において、1.8.1がちょうどリリースされている時に、1.7.xのセキュリティアップデートを作成している.

最新版の1.7か1.8を動かしているならば、合理的にセキュアにすべきであり、知っている限りと、既定値の構成が不必要な脆弱性がないという範囲において、任意の脆弱性はない. もしも、古いバージョンを動かしているか、1.5.xかそれより古いバージョンを津catっているならば、あなたに影響がある問題があり、アップグレードを考えることを強く推奨する.

サーバ上で動いているApache、PHP、MySQLと他のソフトウェアをアップデートすることも忘れないこと -- OSと他のwebアプリケーションもである. wormの圧タックのphpBB中中の欠陥によって、いくつかの人が使っているMediaWiki 1.3.x インストールは2004秋中に影響される;利用者のパッチされてない他のphpBBサイトを通して、それは得られ、それに"you are hacked"というメッセージがシステム上の他の書き込み可能な.phpファイルに追加され、それにはMediaWiki 1.3が使うコンパイルされたテンプレートも含む.

一般的なPHP設定の推奨
ここにはPHP環境に対するよりよい小さなアドバイスがあり、それらはMediaWikiに必須のものではない.

php.iniまたはその他の設定のためのPHP構成の推奨:


 * を無効にする.
 * 多くのPHPセキュリティ攻撃はグローバル変数の価のインジェクションに基づいているので、それをoffにすることは潜在的な脆弱性をなくすことが出来る.
 * もしも他のwebアプリケーションのために を必要とするならば、仮想ホストかそれが必要とするサブディレクトリのみに選択的に有効にすることを考慮すべきである.
 * MediaWikiは、もしもそれがonでもセキュアにすべきである;これをoffにすることは、未知の脆弱性の可能性に対して予防処置を取ることになる.
 * 特にそれを必要としない限り、 を無効にする.
 * リモートPHPコード実行の脆弱性は 又は  をURL中に埋め込むことが可能になることに依存するだろう. もしもリモートファイルロードを必要としないなら、offにすることでこの種の脆弱性コードの攻撃を防ぐことが出来る.
 * MediaWikiはLucene検索拡張、OAI収穫者拡張と1.5中でSpecial:Importのある種の使用のために、この設定をonにすることを要求するかもしれない. これは、しかし、通常のインストール中で要求されない.
 * MediaWikiは、もしもこれがonであっても安全であるべきである;これをoffにすることは、未知の脆弱性の可能性に対する予防策となる.
 * をoffに設定する.
 * もしもこれをonにするならば、セッションIDは、もしもクッキーがその役目を果たさないとき、ときどきURLに付加されるだろう. これはリファラデータかリンクのカットandペーストを通して第三者のサイトにログインセッションデータをもらす可能性がある.
 * 常時もしもこれがonならばoffにすべきである.

php.iniは以下の中に位置する:
 * /etc/php.ini (Red Hat Linux, SuSE / Novell Linux)
 * /etc/php4/apache/php.ini (Debian woody と sarge、 php4とapache 1.3を使うUbuntu 6.10)
 * /etc/php5/apache2/php.ini (php5とapache2を使うUbuntu 6.10)
 * /etc/httpd/php.ini (Trustix Secure Linux 3.0)
 * /usr/local/php/lib/php.ini (Marc Liyanageの PHPパッケージを使うMac OS X)
 * /etc/apache/php.ini (Slackware 10.x)
 * /var/www/conf/php.ini (OpenBSD)
 * /usr/local/etc/php.ini (FreeBSD)
 * /usr/pkg/etc/php.ini (NetBSD)
 * Gentoo Linux:
 * /etc/php/apache2-php4/php.ini
 * /etc/php/cli-php4/php.ini
 * /etc/apache2/php.ini
 * c:\windows\php.ini (Windows)

php.ini中でこの行を見つけたならば、例をあげると:

register_globals = On

を:

register_globals = Off

に変更する. 代替として、これをapacheディレクティブで、ディレクトリ単位にregister_globalsをofにすることが出来る:

php_flag register_globals off

次に変更を再ロードするために、Apacheを再起動する.

ApacheモジュールとしてPHPがインストールされた、複数の人が使うシステムでは、全ての利用者のスクリプトは、同じ、制限された利用者アカウント下で動作する. これは、(データベースパスワードを含む)あなたの構成ファイルを読むためのアクセスと、ログインセッションのデータの読み出しと変更、あるいは(もしも可能ならば)アップロードディレクトリ中に直接ファイルを書くということを、他の利用者に与えるということである.

複数利用者のセキュリティのために、それぞれ固有のアカウント下で各々の利用者のスクリプトを動作させるCGI/FastCGI構成を使うか、他の利用者のファイルへのスクリプトアクセスを制限する、Safe Modeを使うことを考慮する. セーフもーでは、アップロードと、他のプログラムにシェルから抜けられる拡張のようなMediaWikiのいくつかの機能が使えてもよいことに注意.

一般的なMySQLの推奨
一般的に、MySQLデータベースへのアクセスを最小限にすべきである. もしも、それが動作するマシンだけの単一のマシンからのアクセスで使われるならば、ネットワークサポートをやめるか、ローカルなネットワークからのアクセスのみ(以下で説明するように、loopbackデバイス経由で)を有効にすることを考慮し、そうすることで、サーバはUNIXドメインソケット経由でのみローカルクライアントと通信が出来る.

もしも、制限された数のクライアントマシンがあるネットワークで使うならば、それらのマシンからか、あるいはローカルサブネットからのみポート3306(MySQLのポート)にアクセスを認める、ファイアウォールのルールを設定することを考慮し、より大きなネットワークからのすべてのアクセスを拒否する. これはアクシデントによって、MySQL中のいくつかの未知な欠陥にアクセスすることにより、間違ってセットした、overbroad なGRANTやパスワードの漏洩を防ぐのに役立つ.

もしもMediaWikiのインストーラを通じてMediaWikiのための新しいMySQLユーザを作成したならば、何らかの合法的なアクセスを2番目のサーバからローカルのものと同じように動作することを確実にする. 必要に応じて個別の許可を利用者アカウントそれ自身で設定するか、手動で狭めることを考えてもよい.

MediaWiki中の テーブルはハッシュされた利用者のパスワードと電子メールアドレスを含む可能性があり、一般的に個人情報と考えられることに注意.

以下も参照:
 * mysql コマンド行オプション.
 * Setting  in your my.ini (under section  ) will cause MySQL to only listen on the loopback interface. This is the default in the EasyPHP install for Windows
 * GRANT and REVOKE syntax

手動でのインストール
もしも、webベースのインストーラを使うならば、 ディレクトリを書き込み可と ファイルが書き込み中の間に、サーバ上でインストーラを動かしている以外でだれかによって攻撃の可能性がある.

通常、これは非常に大きなリスクではないが、もしもそれが認められないならば(あるいはもしも多数のwikiにバッチでインストールする必要があるならば)、手動でのインストールを考慮する:
 * データベースの作成
 * 利用者のパーミッションの許可
 * Source  to create the tables.
 * Create a  based on a sample or the generation code in , and   based on

もしもPHPがApacheモジュールとして動いているならば、webインストーラによって生成されるLocalSettings.php は、通常Apacheのユーザアカウントによって所有される. これを確実にするために、他の利用者か、(マルチユーザシステムについての上記の注意を参照)か、悪意のある脆弱性のある侵入用webアプリケーションコードによって再度変更できないので、別のアカウントに再割り当てすべきである. (もしも制限されたアクセス権限しか持っていないならば、ファイルを移動する代りにコピーを考慮する;新しいコピーはあなたの権限となる. )

代替のファイルレイアウト
MediaWikiはインストールを容易にするために、ディストリビューションアーカイブから展開された場所で動くようにデザインされている.

しかしながら、大量のインストール中で重複を防ぐか、安全のためにweb rootから重要なファイルを外すために、手動で種々のファイルを統合したり再配置することが出来る.

(メインのincludeとスキンファイルの移動はLocalSettings.php中でinclude_pathの設定を注意深く取り出し、選択、変更することを要求する. )

LocalSettings.phpからデータベースパスワードか個人情報の類を、webドキュメントroot の外側に配置する他のファイルに移動することと、LocalSettings.phpからそのファイルを することを考慮する. これは、webサーバ構成エラーがPHP拡張を無効にし、ファイルのソーステキスト中に暴露されることでデータベースのパスワードが危険に去らされないことを確実にする.

同様に、 を何らかのエディタで変更して、変更されたファイル拡張子で同じディレクトリ中にバックアップファイルをそのままにしておくことは、もしも、だれかが、 として平文テキストで要求する時にコピーを提供してしまうことになる. もしも、そのようなエディタを使うならば、バックアップを無効化するか、web root以外に情報を置く.

利用者のセキュリティ
MediaWiki中の利用者インタフェースメッセージを編集することが出来る:ページレイアウト中にHTMLとJavaScriptコードに名前空間は導入できる. これは、だれでもdatabase中のcurテーブルにアクセスでき直接かけると言うのと同じように、wiki利用者は'sysop'のパーミッションを持つことを意味する.

悪意のあるここへの攻撃が利用者のパスワードを盗聴するために使われるか、ブラウザの脆弱性を使うために使われる(スパイウェアのインストールなど). そのため、信頼できる利用者のみにそれらのパーミッションを設定すべきである.

Upload security
File uploads are an optional feature of MediaWiki and are disabled by default. If you enable them, you also need to provide a directory in the web root which is writable by the web server user.

This has several implications for security:
 * The directory may have to be world-writable, or else owned by the web server's limited user account. On a multiuser system it may be possible for other local users to slip malicious files into your upload directory (see multiuser notes above)
 * While PHP's configuration sets a filesize limit on individual uploads, MediaWiki doesn't set any limit on total uploads. A malicious (or overzealous) visitor could fill up a disk partition by shoving lots and lots of uploads at you.
 * Generated thumbnails and uploaded files held for overwrite confirmation may be kept in images/thumb and images/tmp without visible notice in the MediaWiki web interface. Keep an eye on their sizes as well.

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.
 * Various executable and script extensions are explicitly blacklisted even if you disable the whitelist.
 * Multiple file extensions are checked against the blacklist.
 * Several known image file extensions have their types verified using PHP's getimagesize function.
 * Uploaded files are checked to see if they could trip filetype detection bugs in Internet Explorer and Safari which might cause them to display as HTML.

In case these checks turn out to be insufficient, you can gain further protection by explicitly disabling server-side execution of PHP scripts (and any other scripting types you may have) in the uploads directory (by default, ).

For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:

 # Ignore .htaccess files AllowOverride None # Serve HTML as plaintext, don't execute SHTML AddType text/plain .html .htm .shtml # Don't run arbitrary PHP code. php_admin_flag engine off # If you've other scripting languages, disable them too. 

Your exact configuration may vary

Note that use of PHP's safe mode or open_basedir options may complicate handling of uploads.

External programs

 * may be executed for edit conflict merging.
 * If ImageMagick support for thumbnails or SVG images is enabled,  may be run on uploaded files.
 * If enabled, the texvc math extension will call  executable, which calls ,  , and   (which calls  ).

Fixes for past vulnerabilities
If you are running an older-than-current version of either the 1.4 or 1.3 branches, or a 1.2 or older release, you should upgrade immediately:


 * 1.4.5: fixes template HTML JavaScript injection
 * 1.4.2: fixes JavaScript injection if $wgUseTidy on


 * 1.3.13: fixes template HTML JavaScript injection
 * 1.3.12: fixes JavaScript injection if $wgUseTidy on
 * 1.3.11: fixes several XSS injections, introduces protection against offsite form submission forgery, fixes directory traversal in image deletion
 * 1.3.10: fixes XSS injection, partial protection against offsite form submission forgery; user JavaScript now disabled by default
 * 1.3.9: fix to upload file extension blacklisting if whitelist is too wide is disabled; possible PHP code injection on vulnernable configurations
 * 1.3.7: fixes a bug in handling of protected pages
 * 1.3.4: added upload checks for HTML/JavaScript injection

The 1.2 branch has been discontinued. It's known to contain the template HTML JavaScript injection vulnerability and may contain other problems; upgrading to a current release is strongly recommended.