PukiWiki/1.4/ちょっと便利に/任意のページごとの閲覧・編集制限/未対応プラグイン対策

認証の実装を考える†

2007-11-27 (火) 01:49:49
「PukiWiki/1.4/ちょっと便利に/任意のページごとの閲覧・編集制限/編集認証実装方法案」から変更。

現状について†

PukiWiki/1.4/ちょっと便利に/任意のページごとの閲覧・編集制限にあるように、get_sourceやfileでgrepして、認証対応が必要と思われるプラグインが多数あるが、未だに対応出来ていない。PukiWikiユーザーは、上記ページやdevサイトを注意深く見ていなければ、未対応のプラグインがあることに気づかないため、pukiwiki.ini.phpで認証設定をして、保護されていると誤解してしまうおそれがある。

必要と思われる対応†

案1†

pukiwiki.ini.phpのauth関連の設定箇所に、「未対応のpluginがある。PukiWiki/1.4/ちょっと便利に/任意のページごとの閲覧・編集制限参照のこと」との注意書きコメントを追加する。(これは最低限必要では)

案2†

現状について、で書いたように、get_sourceやfileを使用しているプラグインが認証対応を求められる。それならget_sourceやfile(file_write)関数で制限をしてしまえば良いのでは。
基本的には各プラグインで対応するが、万一漏れていたら、get_sourceやfile_write関数で認証を行い、情報が漏れたり編集権限が漏れたりすることを防ぐ。

編集制限対策案†

lib/file.phpのfunction file_write()で編集認証チェックをする。

function file_write($dir, $page, $str, $notimestamp = FALSE)
{
	global $_msg_invalidiwn, $notify, $notify_diff_only, $notify_subject;
	global $whatsdeleted, $maxshow_deleted;
+	global $editable_flag;

	if (PKWK_READONLY) return; // Do nothing
+	if (defined('PKWK_SECURITY_READONLY')) return; // Do nothing
+	if (!$editable_flag && !check_editable($page, FALSE, FALSE)) {
+		 die('file_write(): not editable');
+	}
	if ($dir != DATA_DIR && $dir != DIFF_DIR) die('file_write(): Invalid directory');

とする。(注 $editable_flagのチェックはcheck_editableより先に行わなければならない。明示的にif文2つに分けた方がよいかな。)

明示的に編集認証を無視する場合には、

	global $editable_flag;
	$editable_flag = TRUE;

を記載する。プラグイン「rename.inc.php」や「unfreeze.inc.php」の様に直接file_write()やpage_write()を呼び出しているプラグインではその前に記載必要。
#commentのように、(一部の人は)書き込み認証に関係なく書き込み可としているプラグインにはreturnの前に記載する。

die()の代わりにreturnとするのでも良いだろう。ただ、本来pluginで編集制限をかけるべきところが、処理が漏れている状態であるので、それが分かるようにdie()という案をあげた。

閲覧制限対策案†

lib/file.phpのfunction get_source()で閲覧権限認証チェックする。

function get_source($page = NULL, $lock = TRUE, $join = FALSE)
{
+	global $readable_flag;
	$result = $join ? '' : array();
 
 	if (is_page($page)) {
+		if (!$readable_flag && !check_readable($page, FALSE, FALSE)) {
+			die('get_source(): not readable');
+		}
		$path  = get_filename($page);

ないとは思うが、プラグイン等で閲覧認証を回避したい場合には

global $redable_flag;
$redable_flag = TRUE;

とする。
die()部分については編集認証と同様でreturnとする案もある。

• 対応必要箇所
  • lib/convert_html.php convert_html()でdigest生成のためにget_sourceを呼んでいる。このdigestは使用されていないようなので、削除する。

    function convert_html($lines)
    {
    	global $vars, $digest;
    	static $contents_id = 0;
    
    ---	// Set digest
    ---	$digest = md5(join('', get_source($vars['page'])));

関連†

• PukiWiki/1.4/ちょっと便利に/任意のページごとの閲覧・編集制限
  • PukiWiki/1.4/ちょっと便利に/任意のページごとの閲覧・編集制限/未対応プラグイン対策
• BugTrack/598 雛形とするページを読むことで、アクセス制限をかけたページを覗くことができる
• BugTrack/657 閲覧できないページが編集できてしまう
• BugTrack/694 templateプラグインでアクセス制限の掛かったページが閲覧できる
• BugTrack2/121 tracker を「追加」する権限を edit_auth で制限できない
  • official:質問箱3/211 tracker で「追加」権限
• BugTrack2/173 閲覧権限のないMenuBarが表示される
• BugTrack2/174 閲覧権限のないページでも，そのページ名がlistなどで閲覧できる
• BugTrack2/197 commentなどの主要プラグインが編集認証に対応していない
• BugTrack2/198 plugin が空ページを返すときの $defaultpage の表示
• BugTrack2/265 tracker、bugtrackプラグインは編集認証を無視してページを作成できる

コメント†

• 提案ありがとうございます。集中管理できるならそれに越したことはありません。こちらでも検証しながら進めなければならなそうですが、1.4.7_1 向けのネタにさせていただきます。気になっているのはこれで実際どう動作するのだろうかとか、カバーできない物がないかどうかとか、二重チェックしかねなくなるのでそれをカバーできないだろうかといった点などがあります -- henoheno 2007-08-19 (日) 00:01:59
• この提案は、この改造のみによって安全性を確保するのが目的ではなく、file_write()を経由するプラグインの認証チェック漏れを防ぐ、補助的な対応と考えています。
  現状のPukiWikiの設計方針は、編集認証は各プラグインで行う、というように理解しています。が、まだ全プラグインの対応は終わっておらず、またいつ全てのプラグインに手がつけられるか分からない状況です。この改造ではfile_write()関数を通るプラグイン全てに対して書き込み認証が有効になりますので、とりあえず仮の対応として有効だと思います。 -- ぃぉぃぉ 2007-08-19 (日) 02:05:45
  • 各プラグインと、file_wirte()でと、2度のチェックになり、冗長なチェックとなりますが、確保される安全性に対して大きすぎるコストとは思いません。このほんの少しの改造で、BugTrack2/265の様なケースも防げます。 -- ぃぉぃぉ 2007-08-19 (日) 02:08:34
• c.f. BugTrack2/291 -- ぃぉぃぉ 2007-11-28 (水) 02:33:39
• c.f. BugTrack2/292 -- ぃぉぃぉ 2007-11-29 (木) 01:25:53
• プラグイン側で書き込みを拒否できるように、PKWK_SECURITY_READONLY を追加。 -- 2010-11-24 (水) 16:31:10
• ↑をどこに追加したのかすぐに判らなかったのでリンク。案2の編集制限対策案 -- 2010-11-24 (水) 18:59:33

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件