WordPressサイトのセキュリティ対策 13選

WordPressサイトのセキュリティの常識をテーマに、脆弱性診断の経験から常識にしたい、WordPressサイトでよく見つかる脆弱性とその対策方法をまとめていきます。

いつもセキュリティナビをご利用いただきありがとうございます！
今回は、導入編として、サイトをオープンするまでに注意しておきたいことを13個まとめました。WordPressサイトということで、WordPressを動かすPHPやWebサーバについても触れています。どのようなセキュリティ問題かは、ブラウザで実際にアクセスしてふ～んと、難しそうで簡単ですので、是非見ていってください。反響がありましたら、第2回の運用編もアップしていきます。

目次

1. WordPressのセキュリティの基礎知識

WordPressのセキュリティの基礎知識をまとめていきます。

1.1. WordPressとは

WordPressとは、オープンソースのブログ用のCMSです。世界で最もシェアが多いといわれるCMSです。CMSの中で最も多くの人に利用され、バグやセキュリティリスク（脆弱性）が報告され、修正されてきた優れたCMSです。

1.2. WordPressサイトの仕組み

WordPressは、MVCではなく、イベント駆動型のアーキテクチャを採用しており、処理の実行される一連の流れのなかで様々なイベントがデフォルトで設定されていて、条件に応じて実行されます。

WordPressはよく重たい！といわれますが、処理の過程で大量のPHPファイルを読み込むため、PHPの速度、メモリやCPUなどサーバのスペックを気にする必要があります。

1.3. WordPressが動作するためのWebサーバ、PHP、MariaDB（MySQL）

WordPressは、PHP言語でプログラミングされていて、投稿データなどデータをMariaDB（MySQL）に保存します。WordPress利用者は、PHPとMariaDB（MySQL）を利用できるようにしたWebサーバにアーカイブを解凍して配置して利用します。

1.4. WordPressの本体、テーマ、プラグイン

WordPressは本体に豊富なベンダーが提供するテーマやプラグインを追加して、サイトを構築します。

テーマは、サイトのレイアウトやデザインを決めるものです。表示内容も動的に変更することができます。

プラグインは、WordPressの機能を拡張するためのツールです。WordPressの本体は、柔軟性を保つため、不必要なコードでふくれあがってしまわないように設計されています。ユーザそれぞれが特定のニーズに合ったプラグインを利用して、カスタム機能を取り入れられるように作られています。

1.5. WordPressサイトの脆弱性

セキュリティ上の欠陥を脆弱性といいますが、WordPressサイトには以下のような脆弱性が生まれます。WordPressの動作環境やWordPressに含まれるものなど上記で見てきましたがそれぞれが脆弱性を生むポイントになります。

• WordPress本体、テーマ、プラグイン自体のセキュリティ上の欠陥
• WordPressの利用者がログインして設定するセキュリティ上の欠陥
• Webサーバ、PHP、MariaDB（MySQL）関連のセキュリティ上の欠陥
• サーバ、ネットワーク関連のセキュリティ上の欠陥

1.6. WordPressのセキュリティ対策

WordPressだけではなく、PHPやMariaDB（MySQL）、Webサーバやネットワークにも目を向けて、セキュリティ対策を行う必要があります。頭かくして尻隠さずという言葉のように、セキュリティは一番危険な脆弱性の危険度合がそのサイトの危険度になります。

WordPressだけに目を向けてはセキュリティ対策にならないということから本記事では「WordPressサイトのセキュリティ」といういい方を採用してみました。

2. よく見つかるWordPressサイトの脆弱性の確認方法、セキュリティ対策の方法

WordPressサイトの脆弱性の確認方法、セキュリティ対策の方法を見ていきます。よく見つかる、簡単に確認できてとっつきやすい、ことを考慮に入れて、13個の観点をまとめています。

2.1. WordPressのバージョンが古い（バージョンがわかる）

WordPressは知名度が高く、脆弱性が出回りやすく、バージョンが古いとリスクが高くなります。また、特に対処しない場合、バージョン情報が露出しますので注意してください。

確認方法

「＜WordPressサイトのURL＞/readme.html」のURLをブラウザのアドレスバーに入力してアクセスしてみてください。また、投稿ページなどWordPressの任意のページを表示し、generatorで検索、あるいはCSSやJSファイルを閲覧します。特に対処されていない場合、バージョン情報が表示されます。

脆弱な理由

WordPressは利用者の多いCMSなので脆弱性情報も流通しています。WordPressのバージョンが古いことがわかると公開された脆弱性を付いた攻撃が行われやすくなります。

• 参考1）NVD National Vulnerability Database
  https://web.nvd.nist.gov/view/vuln/search-results?query=wordpress&search_type=all&cves=on
• 参考2）JVN iPedia 脆弱性対策情報データベース
  http://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja&useSynonym=1&keyword=wordpress

セキュリティ対策の方法

WordPressのインストール媒体は、最新のものを使用してください。脆弱性を修正した最新バージョンが公開されたら、かならず更新でアップデートしてください。プラグインも同様です。

バージョンを隠す場合は、readme.htmlを削除またはアクセス制限し、以下のようなコードをテーマのfunction.phpに記述して、htmlのヘッダにバージョン情報が表示されないようにします。

remove_action('wp_head', 'wp_generator');
foreach ( array( 'rss2_head', 'commentsrss2_head', 'rss_head', 'rdf_header', 'atom_head', 'comments_atom_head', 'opml_head', 'app_head' ) as $action ) {
	remove_action( $action, 'the_generator' );
}

function remove_cssjs_ver( $src ) {
	if( !is_user_logged_in() && strpos( $src, '?ver=' ) )
		$src = remove_query_arg( 'ver', $src );
	return $src;
}
add_filter( 'style_loader_src', 'remove_cssjs_ver', 10, 2 );
add_filter( 'script_loader_src', 'remove_cssjs_ver', 10, 2 );

なお、readme.htmlはアップデート毎に作成されたり、バージョンを隠そうと思っても漏れやすいです。バージョン情報を隠すことにより、攻撃されにくくなる効果はあると思われますが、バージョン情報を隠しても網羅的に公開されている脆弱性が試されたら終わりですので、古いものを使用しないことが重要です。

バージョンを隠す前にアップデートをしてください。もしテーマが対応しないなどアップデートができない理由がある場合は危険ですので、公開スケジュールを延期し、アップデートできるようにしてから運用する判断が必要です。

2.2. WordPressサイトのユーザIDがわかる（?author=数字）

WordPressは、特に対処しない場合、ログイン時に使用するユーザIDが露出してしまいます。

確認方法

「＜WordPressサイトのURL＞?author=数字」のURLをブラウザのアドレスバーに入力してアクセスしてみてください。特に対処していない場合、URLやページソースにユーザIDが含まれるページに遷移します。数字部分は1,2,3・・・と大きな数字にしていくことで、使用しているユーザのIDにたどりつきます。

脆弱な理由

ユーザIDがわかるため、ユーザID固定でパスワードを繰り返し入力するブルートフォースアタックや推測されやすいパスワードを使用して、WordPress管理画面のログインに成功し、編集機能へアクセスされる危険性が高くなります。

セキュリティ対策の方法

パスワードを半角英数字記号を含めて16文字以上にする、ログイン画面を表示しない（アクセス制限する）、以下のようにユーザIDを表示しないようにする対策があります。すべて実施すれば完璧ですが、難しい場合は行えるものを行います。

デフォルト設定ではログインに使うユーザ名と、記事投稿時にサイトに表示される名前が同じなので、記事を見ればログインIDがわかってしまいます。

そのため、デフォルトのユーザ名ではなく、別の名前を新しく設定し、「ブログ上の表示名」に選択します。

加えて、テーマに含まれるfunction.phpに以下のコードを追記します。

function knockout_author_query() {
    // disable author rewrite rule
    global $wp_rewrite;
    $wp_rewrite->flush_rules();
    $wp_rewrite->author_base = '';
    $wp_rewrite->author_structure = '/';
    // for author query request
    if (isset($_REQUEST['author']) && !empty($_REQUEST['author'])) {
        $user_info = get_userdata(intval($_REQUEST['author']));
        if ($user_info && array_key_exists('administrator', $user_info->caps) && in_array('administrator', $user_info->roles)) {
            wp_redirect(home_url());
            exit;
        }
    }
}
add_action('init', 'knockout_author_query');

2.3. WordPressユーザが推測されやすいパスワードを設定する

複数ユーザで運用している場合、ユーザによっては簡単なパスワードを設定してしまう可能性があります。特に、「2.1. WordPressサイトのユーザIDがわかる（?author=数字）」の対策が行われていない場合は危険です。

確認方法

WordPressのユーザIDまたはCopyrightと同じ単語をパスワードにして、全ユーザのログインを確認します。

脆弱な理由

WordPress管理画面のログインに成功し、編集機能へアクセスされる危険性が高くなります。

セキュリティ対策の方法

ユーザIDやパスワードはユーザに設定させるのではなく、システム管理者が発行するなど簡単なパスワードを設定されないよう配慮します。

2.4. ディレクトリリスティング（Index ofページが表示される）

Index ofページが表示され、データベースのバックアップファイルやwp-config.php.bakといったファイルの場所がわかるようになっていることがあります。

確認方法

ディレクトリリスティングが有効になっている場合は、たとえば、「＜WordPressサイトのURL＞/wp-admin/includes/」のURLをブラウザのアドレスバーに入力してアクセスすることでIndex ofページが表示されます。

脆弱な理由

どこにどんなファイルが置かれているかわかるため、WordPressサイトをどのように構成しているかやバックアップファイルなど、見られないと誤認識して置かれたファイルがわかってしまい、情報漏えいしてしまいます。

セキュリティ対策の方法

Web公開用のディレクトリに保管されているファイル群は、基本的に外部から閲覧することが可能です。公開Webページにファイルへのリンクがなくても、外部から直接指定することで閲覧されてしまいます。公開を想定していないファイルは、Web公開用のディレクトリに保管しないようにしてください。

また、今回のように公開を予想していないファイルがあっても見つかりにくくするために、サイトに置かれているファイルへのリンクが表示されてしまう今回のIndex ofページを表示しないように設定してください。

Apacheの場合、Optionsに指定されている「Indexes」パラメータを取り除くか、「-Indexes」に変更します。

2.5. PHPのデバック情報が表示される

ファイルは置かなくても開発時用の設定が有効になっている場合、エラーなどでサーバのパスやファイルの内容が露出する場合があります。

確認方法

たとえば、「＜WordPressサイトのURL＞/wp-content/themes/＜テーマ＞/」は直接アクセスすると「HTTP ERROR 500」になるテーマが多いです。

開発時用の設定が有効になっている場合、これを実行すると、「PHP Fatal error: Call to undefined function get_header() in /home/＜OSユーザ名＞/public_html/wordpress/wp-content/themes/＜テーマ名＞/index.php on line 1」のようなエラーメッセージが表示されます。

脆弱な理由

攻撃者にシステムの情報を与えることによって、様々な攻撃方法に必要なヒントを与えることになります。これによって、攻撃されやすくなります。システム構造が推測できてしまうような情報は、表示しないように注意が必要です。

セキュリティ対策の方法

PHPの設定を「display_errors = Off」に設定します。

2.6. PHPの設定情報の詳細が表示される（?=PHPB8B5F2A0-3C9・・・）

PHPにはexpose_phpという機能があります。これがONの場合、HTTPのレスポンスヘッダにPHPのバージョンが表示される（例X-Powered-By: PHP/5.3.3 ）のはよく知られています。しかし、これだけではなく、PHPの情報まで表示されてしまうことに気づいていないことが多いです。

確認方法

＜WordPressサイトのURL＞/wp-content/themes/＜テーマ＞/index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000でphpinfo()ページが表示される場合は、expose_phpがOFFになっていないです。

脆弱な理由

攻撃者にシステムの情報を与えることによって、様々な攻撃方法に必要なヒントを与えることになります。これによって、攻撃されやすくなります。システム構造が推測できてしまうような重要情報は、表示しないように注意が必要です。

セキュリティ対策の方法

expose_phpの設定をOFFに設定します。

2.7. 検索エンジンに致命的な情報がインデックスされる

GoogleやYahooで検索してみると上述のIndex ofページやバックアップファイル、デバック用のメッセージが出力されたページが検索されます。このようにならないように注意が必要です。

確認方法

検索エンジンに「site:＜URLのドメイン部分＞ Index of」「site:＜URLのドメイン部分＞ error」「site:＜URLのドメイン部分＞ sql」「site:＜URLのドメイン部分＞ test」など、「site:＜URLのドメイン部分＞ ＜キーワード＞」で検索します。

脆弱な理由

検索エンジンで上述の脆弱性が「宣伝」されている状態なので攻撃者に見つかる確率を上げます。攻撃やハッキングに使用するコードをエクスプロイトといいますが、上記のように検索エンジンから情報収集するエクスプロイトのデータベースも存在します。

セキュリティ対策の方法

テストページが公開されないか、知らず知らずにクロールされてしまうものと考え、公開前にチェックします。また、定期的に検索エンジンの登録状態もチェックすることをお勧めします。

2.8. robots.txtに致命的な情報を記載してしまう

検索エンジンに登録されてほしくないページなどの制御のためrobots.txtが作成されますが、robots.txtに攻撃者に見られてはまずいページが記述されていることがあります。

WordPressは、集客用のブログに使用されることが多く、検索エンジンには詳しいけれどもセキュリティ面に詳しくないSEO担当者が知らず知らずに記述してしまうこともあるのではないかと思われます。

確認方法

＜WordPressサイトのURL＞/robots.txt

脆弱な理由

robots.txtにもしbackupディレクトリなどが記述されている場合は攻撃者に見られてほしくない場所の情報を与えてしまいます。優先的に攻められることになります。

セキュリティ対策の方法

robots.txtは誰もが閲覧可能であることを考慮にいれて作成します。

2.9. 自作の脆弱なお問合せフォームを設置する

あと、よく見られるのはWordPressのプラグインを利用しないでお問合せフォームだけ自作していることがあります。そして、自作されたお問合せフォームでXSSが行える脆弱性が見つかることが多いです。

確認方法

自作したお問合せフォームの入力項目に「’>”><script>alert(document.cookie)</script>」のようなHTMLタグを変更する文字列を入力します。入力後、確認画面や確認画面から再度入力画面に戻った時にアラートダイアログが表示される場合は、コードの無毒化処理が不十分です。

脆弱な理由

WordPress本体やプラグインはたくさんの人に利用されてテストされており、自作の方がテスト不足になっていることが多いです。XSSは、ページを改ざんしてユーザをだますことに使われる攻撃です。攻撃に利用された場合、ユーザがメールなどでだまされワンアクションを起こすことにより、情報漏えいやマルウェアダウンロードなどの被害に合う可能性があります。

セキュリティ対策の方法

十分にテストできない場合は、ContactFormなどのプラグインを利用することをおすすめします。

2.10. クリックジャッキングが行える

おそらく9割のサイトが、クリックジャッキング攻撃が行える脆弱性を抱えていると思います。

確認方法

サンプルは＜ターゲットページのURL＞のところを書き換えて、HTMLファイルとして保存すれば実行できます。実行すると、アンケートに答えてくださいというポップアップが表示され、OKを押すとhttps://securitynavi.jp/のページに強制遷移します。

実行した際に、ターゲットページが下に真っ白じゃなくて、表示されたらクリックジャッキングの脆弱性ありということになります。

<frameset cols="100%,*" onmouseover="alert('ログインしてください。');
location.href='https://securitynavi.jp/';">
<frame src="＜調査ページのURL＞"></frame>
</frameset>

脆弱な理由

クリックジャッキングは、Frameタグを利用した攻撃で、XSSと同様にユーザがメールなどでだまされワンアクションを起こすことにより、情報漏えいやマルウェアダウンロードなどの被害に合う可能性があります。

セキュリティ対策の方法

クリックジャッキングの脆弱性とは、Webサイトのコンテンツ上に標的サイトのコンテンツを重ねて配置することにより、利用者を視覚的にだまして不正な操作を実行させる攻撃を許す脆弱性のことです。攻撃にはFrameタグが使用されます。HTTPヘッダにX-Frame-Optionsが指定されていない場合に実行できてしまいます。

この攻撃はFrameタグを利用しますので、Frameタグが利用できないようにすることで対策が行えます。フレームタグは、HTTPヘッダのX-Frame-Optionsを設定することで無効にできます。

Apacheで設定する場合は以下を追加します。

Header always append X-Frame-Options SAMEORIGIN

2.11. HTTPSで表示しない、HTTPで表示できる

HTTPSでアクセスすることにより、通信が暗号化されて、通信経路での盗聴や改ざんが防止できます。HTTPSのアクセスは、セキュリティ面だけではなく、Googleの評価やブラウザの表示など、SEOにも影響するといわれています。

確認方法

ブラウザのアドレスバーで、URLのhttps://ではなく、http://にしてアクセスします。

脆弱な理由

HTTPでは、通信データが平文でネットワークに流れるため、パケット盗聴による重要な情報の窃取や改ざんされるといった仕様上の脆弱性が存在します。特に認証を行う画面ではHTTPSを必ず使用するようにしなければなりません。情報漏えいはなくても改ざんの可能性があるので、全ページHTTPSで表示した方がいいです。

セキュリティ対策の方法

SSLを設定していない場合はSSLを設定します。

また、HTTPSで表示されるようにStrict-Transport-Securityヘッダの設定により、HTTPSページが優先的に表示されるようにします。

Apacheで設定する場合は以下のように設定します。

Header add Strict-Transport-Security "max-age=15768000"

なお、リダイレクト機能を利用する方法もありますが、リダイレクトする際にhttpで表示される場合そこでパケット改ざんに遭う恐れがあるため、上記の対策をおすすめします。

2.12. SSLを設定したのに致命的なSSL設定ミスがある

SSLを設定して、HTTPSでアクセスできるようにしているサイトもSSLの設定に不備があることが多いです。

確認方法

SSLサーバ証明書ベンダーなどが提供するオンライサイトのチェックツールを利用することで簡単にSSLの設定不備がチェックできます。ここではSSL LABSを利用してチェックしていきます。

「https://www.ssllabs.com/ssltest/」にアクセスして、URLをフォームに入力するだけでチェックが行えます。

脆弱な理由

SSLに不備があると目的のパケット盗聴による重要な情報の窃取や改ざんの対策が行われていないことになります。

セキュリティ対策の方法

上述のようなテストツールが指摘する脆弱性を対処します。

2.13. WordPressが重たい、チューニング不足、リソース不足で落ちる

WordPressは非常にリソースを食います。その主な原因は大量のPHPファイルにあります。PHPの高速化のチューニング、十分なスペックのサーバで動作させる必要があります。

確認方法

たとえば、jmeterやApache Benchで負荷がけを行って、想定されるアクセス集中時に、最低限、秒間20～30程のボットによるクロールに耐えられるか確認します。1時間程度流して、メモリ不足でMariaDB（MySQL）が落ちて「データベース接続確立エラー」が表示されるなどの事象が発生しないことを確認します。

脆弱な理由

サイトが落とされやすい場合、営業が行えなくなります。

セキュリティ対策の方法

秒間4GなどのDDoS攻撃など簡単に対応できない場合もありますが、少なくともボットアクセス程度で落ちないようにサーバのリソース、PHPやミドルウェアのチューニングは行っておきたいです。

2.14. その他、おすすめのプラグイン、テーマなど

セキュリティの観点で言えば、おすすめのプラグイン、テーマはない、です。

サードパーティ製のプラグインやテーマは、利用者の母数、検証、バグ改修など、WordPress本体に比べ、精緻レベルが低く、セキュリティレベルが低いと考えます。プログラムが増えれば増えるほどソフトウェアのバグは比例して増える事実があります。また、攻撃者は、WordPressの本体のバージョンと同様にプラグインのインストール状況、バージョンを調べて、攻撃に使える脆弱性を調べます。

ですので、プラグインやテーマは極力増やさない方がセキュリティレベルが高いです。少し極端に書きましたが、計画性もなく、検証もせずに、不用意に公開環境へプラグインを入れてしまうのはおすすめできません。もし未使用のプラグインやテーマがインストールされている場合は削除しないとダメです。

上記とは別ですが、WPScanなどスキャンツールを利用することで効率的にチェックは行えますが、観点が不十分ですので、まずは、上記を参考に知識を拡充していただければと思います。

サーバやネットワークなど他にもたくさんありますが、今回はここまでになります。

3. まとめ

最後にWordPressのセキュリティについてまとめます。

3.1. WordPressとセキュリティ

WordPressは世界で多くの利用者がいるCMSです。多くの人に利用され改善される、一方で脆弱性もたくさん公開されています。セキュリティ対策として、最新に保つことは必須です。また、WordPressだけに目を向けず、WebサーバやPHP、MariaDB（MySQL）など利用するソフトウェアのセキュリティ対策も行わないと、セキュリティ対策にならないです。セキュリティのプラグインを探す前にサイト全体的にセキュリティリスクはないか点検していただければと思います。

3.2. WordPressの脆弱性を把握し、セキュリティ対策しよう！

今回のよく見つかるWordPressサイトの脆弱性をまとめましたのでそれを参考に知識を拡充していただければと思います。全体的に脆弱性を把握し、優先度を付けてセキュリティ対策を継続的に実施していっていただければと思います。