WordFes Nagoya 2015 の発表資料。 カスタム投稿や Settings API等、WPの標準機能を使って、効率よく、安全にカスタマイズする方法を紹介。 自己流で脆弱性を引き起こした事例も紹介

1. 管理画面を効率よく、安全に
作成する方法
水野 史土
https://rescuework.nagoya/

2. 自己紹介 水野 史土 (みずの ふみと)
レスキューワーク株式会社 (名古屋市 八事)
企業のホームページ運用サポート
CMSの初期設定: 万人がある程度満足するもの
↓
使う人の要望に応じてカスタマイズし、
更新しやすくして提供する

3. セッションの目標
効率よく、かつ、安全に作成する
▲ 安全だが、作成に手間がかかる方法
=> 実際には使われない可能性がある
● 安全で、開発の効率も良い方法

4. WordPress の管理画面
● 自由に作ることができる
○ 独自機能を追加しやすい
○ 運用しやすい
● しかし、自己流に作ると...
○ 時間がかかる
○ バグ(脆弱性)が生じやすい

5. WPの機能を活用して管理画面を作る
● 開発効率が良い
○ データベースへの更新などをWPが行ってくれる
● セキュリティ機能をWPが面倒見てくれる
○ WPにバグが無い限り安全にカスタマイズできる

6. 本日取り上げるもの
● カスタム投稿タイプ (WP3.0～)
○ データ更新やファイルアップロードなどの機能がある管
理画面を容易に作成可能
● Settings API (WP2.7～)
○ SQLインジェクション、CSRFに対応した管理画面を作成
する機能

7. サンプルのプラグイン
● スライダー画像
○ 画像とタイトルを管理画面から入力する
○ 表示する枚数や順番を管理画面で設定する
このケースで、安全に開発してみよう

8. スライダー画像を表示させる
● 画像とタイトルを入力する
○ カスタム投稿タイプ
● 表示する枚数や順番を管理画面で設定する
○ Settings API

9. カスタム投稿タイプ

10. カスタム投稿を作る
function my_slider_settings_post_type() {
register_post_type( 'myslidersettings', array(
'label' => 'スライダー',
'show_ui' => true,
'supports' => array( 'title', 'thumbnail' ),
) );
}
add_action( 'init', 'my_slider_settings_post_type', 1 );

11. カスタム投稿を作る
function my_slider_settings_post_type() {
register_post_type( 'myslidersettings', array(
'label' => 'スライダー',
'show_ui' => true,
'supports' => array( 'title', 'thumbnail' ),
) ); タイトルとアイキャッチのみのカスタム投稿
}
add_action( 'init', 'my_slider_settings_post_type', 1 );

12. 投稿画面とほぼ同じUI
WPの更新機能を使う

13. WPのファイルアップロード機能

14. カスタム投稿の管理画面
● 通常の投稿とほぼ同じUI、機能
○ 下書き／公開等もそのまま使える
● 様々な処理をWPに任せられる
○ データベースの更新
○ ファイルアップロード

15. Settings API

16. Settings APIで管理画面を作る

17. add_options_page

18. add_settings_section

19. add_settings_field

20. function num_of_slides_callback_function() {
echo '<input name="my_slider_settings_num_of_slides" id="
my_slider_settings_num_of_slides" type="text" value="';
form_option( 'my_slider_settings_num_of_slides' );
echo '" />';
}

21. function num_of_slides_callback_function() {
echo '<input name="my_slider_settings_num_of_slides" id="
my_slider_settings_num_of_slides" type="text" value="';
form_option( 'my_slider_settings_num_of_slides' );
echo '" />'; DBから取得し、エスケープ処理を行って出力する form_option
}

22. 更新後のメッセージ

23. 入力値検証とエラーメッセージ

24. 入力値検証とエラーメッセージ
● データ検証を通らない場合、エラーを出せる
○ エラーメッセージの表示処理もWPに任せられる
○ 画面遷移などのコードを書く必要なし
http://wpdocs.osdn.jp/データ検証
http://php.net/manual/ja/function.filter-var.php

25. Settings APIで管理画面を作る
● WPのオプション画面とほぼ同じUI
● DBへの更新処理をWPに任せられる
● 画面遷移のチェックをWPに任せられる

26. WPの機能を使う

27. SQLインジェクション
● DBに値を渡すとき、命令になってしまう
○ 意図していない書き込み、削除など
SQLを自分で作ると、脆弱性が生じやすい
■ WPの機能を使う (自分でSQLを書かない)
カスタム投稿、settings APIなどを使う

28. ファイルのアップロードの脆弱性
● 不正なファイルをアップロードされる
○ プログラムファイルをアップロードされ、実行される
入力ファイルの検証、ファイル名、ファイルの保存
場所など、様々なチェックが必要
■ WPの機能を使う (自分で処理を書かない)

29. クロスサイトリクエストフォージェリ CSRF
● 通常のフロー: 「編集」→「更新」
○ 直接「更新」できてしまう脆弱性
○ 別サイトのリンクを踏む => 意図せず、更新してしまう
ページにトークン (攻撃者が推測困難な値)を入れる
■ WPの機能を利用する (自分で実装しない)

30. ※ クロスサイトスクリプティング XSS
● データをそのまま出力してしまい、意図しないス
クリプトを実行してしまう
○ <script>... をそのまま出力する
出力時のエスケープ
■ 管理画面側はWPの関数を使えばほぼOK
form_option, checked, selected

31. WPの機能を使うと安全？

32. WPの機能を使うと安全？
● 多くのユーザーが見ている
○ バグがあっても発見されやすい
● オープンソース
○ 発見した人が修正できる
● 自動アップデート
○ 修正作業が楽

33. 自己流で構築して
脆弱性を作りこんだケース

34. 自己流で脆弱性を作りこんだケース1
● timthumb.php を使ったテーマ・プラグイン
○ ファイルアップロードするスクリプト
○ 脆弱性が見つかり、修正された

35. 自己流で脆弱性を作りこんだケース1
● timthumb.php を使ったテーマ・プラグイン
○ ファイルアップロードするスクリプト
○ 脆弱性が見つかり、修正された
↓
WordPress標準のコードではなかったため、
自動アップデートされず、脆弱性が長期間残った

36. 自己流で脆弱性を作りこんだケース2
● Acunetix WP Security 4.0.3
● All in One WP Security & Firewall 3.8.9

37. 自己流で脆弱性を作りこんだケース2
● Acunetix WP Security 4.0.3
● All in One WP Security & Firewall 3.8.9
↓
Settings API を使わないで管理画面作成
不正操作(CSRF)脆弱性が見つかる

38. WPの機能を使った場合

39. カスタム投稿とSettings APIで
● SQLの作成をWPに任せられる
● ファイルアップロードをWPに任せられる
● CSRF対策をWPに任せられる

40. カスタム投稿とSettings APIで
● SQLの作成をWPに任せられる
● ファイルアップロードをWPに任せられる
● CSRF対策をWPに任せられる
↓
自前で作るよりも速く作れる
WPにバグが無い限り、安全に作れる

41. 自己流でコードを書くより
WPの機能を使うほうが安全

42. クロスサイトスクリプティング
には注意する

43. XSS対策は難しい
● 出力箇所ごとに処理が異なる
○ 属性は esc_attr
○ URLは esc_url
● HTMLタグを許可する場合
○ wp_kses_post
フロントエンド側では、様々なHTMLを生成するの
で注意が必要

44. settings APIの
その他のメリット

45. 別プラグインから項目追加
別のプラグイン

46. 別プラグインから項目追加
別プラグインを有効
にして、項目を追加

47. エラー等も共通の管理画面で表示

48. 項目の差し替えも可能
更新する人の好みに合わせてカスタマイズ可能

49. 別プラグインで管理する
● ベースのプラグインを作成しておく
○ 顧客の要望に応じて、追加プラグインを導入する
● プラグインの開発を分担する
○ 複数人で開発する
○ 別の会社と協業する

50. 他者作成のプラグイン
● 他者作成のプラグインをカスタマイズ
○ 他者作成のプラグインに設定項目を追加する
○ 同一ページに表示できる
■ 更新処理やエラーメッセージを共通にできる

51. 他者作成のプラグインを
改変できるのか？

52. WordPressはGPLライセンス
● GPL = 自由に改変できる
○ WP本体を自由に改変できる
○ 派生物(プラグインやテーマ)も自由に改変できる

53. WordPressはGPLライセンス
● GPL = 自由に改変できる
○ WP本体を自由に改変できる
○ 派生物(プラグインやテーマ)も自由に改変できる
↓
他者作成のプラグインを改変できる
開発効率が良い

54. 公開する場合

55. 公式ディレクトリに公開する場合
● テーマとプラグインの役割分担
○ テーマは見た目を扱う
○ カスタム投稿タイプ等の機能はプラグインの領域
公開するときは、ガイドラインを守る

56. settings API の注意点

57. 実装方法が古い
● WP2.7 は2008年末リリース
○ settings API の仕組みもその頃に作成された
○ オブジェクトではなく、関数ベース
○ モダンなフレームワークと比較すると見劣りする

58. 標準でないプラグインの存在
● settings APIを使っていないプラグイン
○ 公式ディレクトリに掲載されているものもある
○ 事情があって使わない場合でも注意書きが無い
■ 例: ajaxを使いたいので独自実装

59. まとめ

60. WordPressのカスタマイズ
● 効率よく開発する
○ カスタム投稿タイプやSettings APIといった、WPの標準
機能を活用する
● 安全に開発する
○ WP本体の機能を使うことで、WPと同等のセキュリティ
水準で開発できる

61. ご清聴
ありがとうございました