ワナビーWPプラグイン開発者として、私が探すべき主なセキュリティ上の欠陥/穴は何ですか?
私は設定パネル(すなわち入力フィールドともの)で新しいプラグインを作成しようとしています。私は何を心配すべきですか?
たとえば、/ wp-admin /エリアにあるため、データのサニタイズはそれほど大きな問題になりますか。悪意のある人が直接私のプラグインページにアクセスしてPOSTリクエストを送信することはできますか
ありがとうございました!
これは私の現在の(進行中の)設定/データセキュリティチェックリストをテーマのレビューに使用するために変更されたチェックリストです(原則はプラグインの場合とテーマの場合の違いは変わりません)。
プラグインは、すべてのオプション、カスタム関数、カスタム変数、およびカスタム定数の前にplugin-slugを付ける必要があります。
以下のような時代遅れで、適切なデータセキュリティを含まないコピーアンドペーストスクリプトに頼るのではなく、プラグインはプラグインオプションとプラグイン設定ページを慎重に実装する必要があります。
トップレベルのメニューを追加するためにadd_options_page()
を使用するのではなく、プラグインはadd_menu_page()
関数を使用してPlugin Settings PageをSettings
メニューに追加する必要があります。
設定ページを追加する機能には、プラグインは適切な機能(例:manage_options
)を使用する必要があります。
設定ページに複数のオプションを作成するのではなく、プラグインはオプションを単一の配列に保存する必要があります。 Settings API(下記参照)を使用するとこれを処理できます。
プラグインは$_POST
と$_REQUEST
データに直接頼るのではなく、Settings API(下記参照)を使ってフォーム入力データを取得し保存するべきです。
チェックボックスと選択オプションについては、プラグインはそれぞれchecked="checked"
とselected="selected"
を出力するためにchecked()
とselected()
関数を使うべきです。
プラグインは、データベースにデータを入力する前にすべての信頼できないデータを検証およびサニタイズし、Settingsフォームフィールドに出力される前およびテーマテンプレートファイルに出力される前にすべての信頼できないデータをエスケープする必要があります。
プラグインはテキスト入力にはesc_attr()
を、テキスト領域にはesc_html()
(またはWP 3.1のesc_textarea()
)を使うべきです。
Settings APIを使用していない場合は、プラグインが明示的にSettings-page nonce検査を提供する必要があります。
また、PluginsがSettings APIを使用することを強くお勧めします。これは、より使いやすく、より安全で、設定ページの大変な作業の多くを処理します。
設定APIの使用に関する優れたチュートリアルについては、以下を参照してください。
http://www.chipbennett.net/2011/02/17/incorporating-the-settings-api-in-wordpress-themes/
http://planetozh.com/blog/2009/05/handling-plugins-options-in-wordpress-28-with-register_setting/
安全でしっかりとコーディングされたテーマ設定ページでテーマをチェックアウトしたい場合は、このテーマをチェックしてください。
http://wordpress.org/extend/themes/coraline
これには2つの側面があります。
基本原則
詳細
defined('ABSPATH') or die('Access denied');
を追加する