データベースを使用するためWordPressのプラグインとして置いているWebゲームがあり、それを管理するプラグインがあります。 その管理プラグインは外部からの入力等がなく、管理画面のサイドメニューからのみでのDB操作機能を持っているのですが、このファイルのパーミッションを600にした場合は、WordPressが乗っ取られない限り外部からの脆弱性はなくなりますか？
600にしても「WordPress がその PHP を実行できるなら」、脆弱性そのものは消えません。
まず重要な点
PHPファイルのパーミッション 600 は：
rw-------つまり：
- 所有者のみ読み書き可能
- グループ/その他はアクセス不可
です。
しかし 一般的な共有サーバでは、
- PHP実行ユーザー
- ファイル所有者
が同一扱い（suEXEC / FastCGI系）
になっていることが多く、
WordPress が読める = PHPも実行可能
です。
つまり：
require 'admin-tool.php';できるなら、600 でも実行されます。
なので本当の問題は
「外部入力がそのコードへ到達できるか」
です。
ここがセキュリティの本質です。
安全性の考え方
例えば：
/wp-admin/admin.php?page=mytoolのみで動き、
- 管理者ログイン必須
- nonceチェック
- capabilityチェック
- 外部POST無し
- AJAX無し
- REST無し
なら、かなり安全です。
この場合、
攻撃者はまず：
- WordPress侵入
- 管理者権限奪取
が必要になります。
つまり：
「WordPress本体が突破されない限り到達困難」
という状態になります。
これは実際かなり強いです。
ただし「完全に脆弱性ゼロ」にはならない
理由はいくつかあります。
1. WordPress内部から読める
もし他プラグインに脆弱性があり：
include($_GET['file']);みたいな Local File Inclusion（LFI）があると、
600 のファイルでも WordPress 権限で読まれる可能性があります。
つまり：
- PHPプロセスが読める
- WordPress内部コードが読める
なら突破され得ます。
2. 管理画面経由CSRF
もし：
if ($_POST['delete']) {
...
}のような処理があり、
- nonce無し
- 権限チェック無し
だと、
管理者がログイン中に悪意サイトを踏むだけで実行されます。
これが CSRF。
3. 管理者権限奪取後は実行可能
当然ですが：
- 管理者アカウント流出
- XSS
- Cookie窃取
されると、
管理プラグインへ到達されます。
本当に強くする方法
最重要
管理処理側で：
current_user_can('manage_options')を必ず確認。
さらに：
check_admin_referer()で nonce。
これが超重要です。
かなり安全な構成例
if (!defined('ABSPATH')) exit;
if (!current_user_can('manage_options')) {
wp_die('Forbidden');
}
check_admin_referer('my_action');これだけでもかなり違います。
実は「600」より有効なもの
1. 直アクセス禁止
例えば：
if (!defined('ABSPATH')) exit;これ。
これだけで：
https://example.com/wp-content/plugins/xxx/admin.php直叩きが無効になります。
WordPress経由でしか動かなくなる。
これは非常に重要。
2. 管理用処理を web 公開領域外へ置く
Xserverでは難しい場合もありますが理想は：
/private/へ置く。
ただ WordPressプラグイン文化的には現実的でないことも多いです。
コメント