WordPress セキュリティを考える会第三回を開催しました。第一回、第二回は東京での開催でしたが、今回は名古屋(株式会社ニューキャスト セミナールーム、愛知県名古屋市東区葵3-22-8)で開催しました。

東京と名古屋と、開催地が異なることもあり参加者が被らなかったため、前半は第二回の資料をベースにしました。

プラグインを作るときのお作法について。関数等に前置詞(プレフィックス)を付けることで、WordPress 本体の関数名とバッティングすることが防げます。とはいえ、前置詞を付けていないプラグインもあります。そのような場合は、プラグインを修正してください。

セキュリティ面でも、お作法が用意されています。特にスライドで取り上げた、「SQL インジェクション対策にプリペアードステートメントを使う」「CSRF 対策に、settings API(nonce を自動発行してくれる)を使う」は、ガイドラインに従うと、ほぼ確実に(=WP本体にバグが無い限り) SQL インジェクション／CSRF を防ぐ事ができます。とはいえ、こちらもガイドラインに従っていないプラグインがあります。公式ディレクトリに登録されているプラグインでも、ガイドラインに従っていないことがあるのでご注意ください。

後半では、個別のプラグインを取り上げて、コードの書き方等をチェックしました。$_POST をそのまま使っていたり、wpdb::prepare の使い方がおかしかったり、様々な問題が見つかりました。ダウンロード数が多い事や、公式ディレクトリでユーザーの評価が高い事は、プラグインの機能や使い勝手の評価には参考になります。しかし、ガイドラインに従っているか、セキュリティ面で不安は無いか、といった評価とは結びつきません。

なので、もしプラグインを使うのであれば、実装がきちんとしているかどうか自分で調べる、という作業が必要になりますね。個人のブログならまだしも、お客さんのサイトでプラグインを使用するのであれば、使用するプラグインのチェックは必須となるでしょう。

次回以降の開催計画は、http://wpsecurity.doorkeeper.jp/でお知らせします。