このページの本文へ

ESET/サイバーセキュリティ情報局

世界シェア1位のCMS「WordPress」が抱えるセキュリティリスク

  • この記事をはてなブックマークに追加
  • 本文印刷

本記事はキヤノンマーケティングジャパンが提供する「サイバーセキュリティ情報局」に掲載された「WordPressに迫るセキュリティリスク?被害事例から考える代替策とは?」を再編集したものです。

 WordPressは世界シェア1位のCMSである一方、サイバー攻撃のターゲットにされやすいことで知られる。実際、過去にさまざまな脆弱性を狙った攻撃が発生している。この記事では、WordPressが抱えるセキュリティリスク、実際の被害事例を踏まえ、安全な運用に必要な対策にあわせてWordPressを代替する選択肢についても解説する。

WordPressが抱えるセキュリティリスクとは

 WordPressは世界で最も多く利用されているCMSであり、そのシェアは6割を超えることが知られている。その圧倒的とも言える利用率の高さが、一方でサイバー犯罪者に狙われやすい理由ともなっている。実際、WordPressを導入したウェブサイトを狙う攻撃は後を絶たない。一般的に知られる、WordPressのリスクは以下のとおりだ。

1) 不正アクセス

 何かしらの脆弱性を突き、攻撃者はWordPressの管理画面やデータベースへ不正アクセスする。不正アクセスをされることで、情報の改ざんや機密情報の窃取などさまざまな被害を受けるリスクがある。

2) ウェブサイト改ざん

 ウェブサイトの情報を不正に改ざんされてしまう。それにより、ウェブサイトの来訪ユーザーを偽のページへ誘導したり、マルウェアをダウンロードするよう仕向けたりといったことが攻撃者によって行なわれる。

ウェブ改ざんはどのように行なわれるのか? その手口と対策
https://eset-info.canon-its.jp/malware_info/special/detail/210105.html

3) 意図せぬ犯罪への加担

 ウェブサイト改ざんによって来訪ユーザーをマルウェア感染などのリスクに巻き込むだけでなく、DDoS攻撃踏み台にされるケースもある。また、知らないうちにサイバー攻撃に利用されてしまう懸念もある。

4) 情報漏えい

 ウェブサーバーに個人情報や機密情報などが存在する場合、それらが漏えいするリスクがある。仮に情報が漏えいしてしまうと、企業の信頼を損なうだけでなく、損害賠償などの訴訟に発展する恐れもある。

WordPressに起因する被害事例

 WordPressに起因する被害はどのように生じるのだろうか。以下、実際の被害事例を紹介していく。

1) 企業のウェブサイトがWordPressの脆弱性を突かれ改ざん

 2021年、ある企業のウェブサイトがWordPressの脆弱性を突かれて改ざんされた。当該ウェブサイトへアクセスすると、悪意のある外部サイトへ誘導される状態となっていた。

 原因はWordPress本体のアップデート漏れにより、脆弱性が放置されていたことであった。同ウェブサイトのデータを保存しているレンタルサーバー側が、最新のWordPressに対応していなかったことで、CMS本体がアップデートされなかったことが主な要因だ。サーバー内に機密情報、個人情報などは格納されておらず、情報漏えいは発生しなかったとされる。同社ではWordPressを最新の状態に保つことと、WAF(Web Application Firewall)を導入するという運用方針を示した。

2) 女性向けファッション事業を手掛ける企業のウェブサイトがスパム攻撃の踏み台に

 2017年、女性向けファッション事業を手掛ける企業のウェブサイトが不正アクセスを受けた。原因はウェブサイト制作のテスト環境にインストールしたWordPressと、そのプラグインの脆弱性を突かれたことだった。テスト環境内のWordPressとプラグインをアップデートせず放置していたとされる。改ざんによりメール送信機能を悪用され、大量のスパムメール送信の踏み台にされてしまった。

3) 官公庁の実証事業のウェブサイトが改ざん、外部サイトへ誘導

 2018年、国内官公庁が管轄するウェブサイトが改ざんされ、悪意のある外部サイトに誘導される状態となっていた。ウェブサイトにはフィッシングサイトなど、ほかの正規ウェブサイトから盗用したと思われる偽のページが複数掲載されていた。原因は放置されたWordPressの古いプラグインの脆弱性にあったと推測されている。

 上記の例のように、WordPressにおけるセキュリティリスクは、CMS本体だけでなく、プラグインの脆弱性に起因するものも多い。本来、ソフトウェアのバージョンは適切に管理を行ない、常に最新にアップデートするべきである。しかし、WordPressやプラグインは費用が掛からず容易に導入できてしまうこともあり、導入後に放置されてしまうケースも少なくないというのが実情だ。

WordPressの安全な運用のための8つの対策

 WordPressは費用を掛けずに導入でき、ウェブサイト運営を効率化できるCMSであることは間違いない。その利便性を享受するためにも、セキュリティ対策を適切に講じておく必要がある。WordPressを安全に運用するための取り組みとして代表的なものは以下のとおりだ。

1) プラグインやテーマも含めたバージョン管理

 先述のとおり、WordPress本体はもちろんプラグインなども含め、適切なバージョン管理を行なうことは基本的かつ重要な取り組みだ。自らが携わるウェブサイトで利用するプラグインやテーマについては、アップデート情報を常にチェックし、更新プログラムが配布されたら滞りなく適用するようにしたい。

2) 定期的なバックアップの取得

 ウェブサイト制作、運用の基本でもあるが、バックアップは必ず定期的に行なうようにしたい。バックアップがあれば、仮に不具合が生じた場合にもバックアップ時点の状態に復元することが可能だ。また、その際にはWordPress本体と格納されているファイルだけでなく、MySQLなどのデータベースもバックアップを取得するようにしておくこと。

3) アカウント情報の適切な管理

 管理画面への認証情報が漏えいしないよう、パスワードマネージャーの利用やウェブブラウザーのパスワード管理機能を利用すること。また、マスターパスワードは厳重に管理することも徹底してほしい。WordPressでは二段階認証を導入できるプラグインもあるため、こうしたオプションの利用も検討したい。

4)セキュリティ用プラグインの導入

 WordPressにはSiteGuardなどの著名なものをはじめ、さまざまなセキュリティ用のプラグインも存在する。管理画面のURLの変更やアクセス制限なども可能なため、導入することで安全性が高まる。ただし、プラグインは導入前に提供元の信頼性を確認しておくことや、アップデートを怠らないようにしてほしい。

5)WAFの導入

 WAF(Web Application Firewall)はウェブアプリケーションの脆弱性を狙う攻撃を防ぐ役割を担う。WAFの導入により、脆弱性を突いた攻撃やSQLインジェクションなどの代表的なサイバー攻撃のリスクを低減できる。

WAFとは? ウェブサイトのサイバー攻撃を防ぐ決定打となり得るのか?
https://eset-info.canon-its.jp/malware_info/special/detail/220208.html

6)保守・運用の委託

 バージョン管理を行なう方法のひとつとして、WordPressおよびプラグインの保守・運用を外部パートナーに委託する方法も有効だ。ウェブサイト制作会社などに依頼する場合、アップデートする際のバックアップや、更新時に表示崩れなどの異常があった際のロールバックや修正対応まで可能なケースもある。

7)アドバイザーや相談窓口の確保

 WordPressはプラグインをはじめ、セキュリティを取り巻く環境はめまぐるしく変わっていく。しかしながら、専任のセキュリティ担当を自社に置くことが難しい企業も少なくないだろう。そのような場合、状況をキャッチアップするために外部のアドバイザーを活用するという方法がある。自治体によってはサイバーセキュリティに関する相談窓口が設置されていることもあるため、それらの利用も検討に値する。

8)情報収集

 WordPressやプラグインの脆弱性に関する情報収集も欠かせない。IT系のウェブメディアなどでも報道されることが多いが、下記のようなセキュリティ専門機関が発する情報も適宜チェックするようにしておきたい。

・IPA(独立法人 情報処理推進機構)の脆弱性対策情報
・JVN(Japan Vulnerability Notes)の脆弱性対策情報データベース検索

今一度、おさらいしておきたいWordPressのセキュリティ
https://eset-info.canon-its.jp/malware_info/special/detail/210120.html

WordPressを利用しないという選択肢

 無料で導入できるというメリットが、WordPressの普及が進んだ要因のひとつでもある。また、テンプレートやプラグインなどの充実も利用を後押ししている。しかし、利用する企業・組織、ユーザーが増えるにつれ、取り巻く状況は大きく変わってきている。そして、そのエコシステムの拡張と歩調を合わせるように、サイバー攻撃者に狙われるリスクも高まってきている。

 ここまでリスクが増大している状況を考慮すると、「WordPressを利用しない」という選択肢もあって然るべきだろう。以下、代替策となるものを挙げていく。

1) 機能特化型の簡易型CMSの利用

 WordPressを利用するという選択について、熟考を重ねずに決定したという企業・組織も少なくないはずだ。あるいは、ウェブサイトの制作段階では、現時点のようなセキュリティリスクを抱えることを想定できなかったというケースもあるだろう。

 CMSを使う場合、多くの機能を有するWordPressではなく、シンプルな更新機能のみに特化した、簡易型のCMSという選択肢もある。更新ページが限定的な場合、こういったシンプルなCMSを利用することも一考に値する。ただし、WordPress以外のCMSであっても、一定のリスクが生じ得ることは認識しておきたい。

2) HTMLのみの静的なウェブサイトへの置換

 ウェブサイトによってはそもそもCMSを利用する必要がないケースもあるだろう。例えば、アップされているページの更新頻度が低く、内容も会社案内や簡潔なサービス紹介程度であれば、静的なHTMLに置き換えるという選択肢もある。問い合わせフォームも廃止し、LINE@やFacebookのビジネスページを利用すれば、リスクは限りなく軽減される。

 自社サイトのこれまでの運用状況を振り返り、今後も更新頻度が高くないことが見込まれるのであれば、そもそもサイト自体を閉鎖して、FacebookページやInstagramで代替するという方法を検討しても良いだろう。

 なお、簡易型CMSでも静的なHTMLのみのウェブサイトでも、サーバーを用意することはWordPressと同様だ。そのため、いずれにせよサーバーへの侵入を防ぐための対策は講じる必要性がある。仮にサーバーに侵入されてしまえば、ウェブサイトの改ざんや踏み台として利用されるなど、何かしらの被害を受けることになってしまうからだ。

3) SaaS型「ホームページ制作ツール」を利用

 近年、導入側でサーバーを用意せずウェブサイトを運用できるサービスも登場している。代表的なサービスとして、Jimdo、Wix、Strikinglyなど国外の事業者が提供しているものが知られているが、国内発のサービスもリリースされている。これらはSaaSとして提供されるサービスであるのが大きな特徴だ。

 SaaSであるため、サービス自体のアップデートなどはユーザー側で行なう必要はない。CMSとしての機能がウェブサービスとして提供されるため、WordPressのように本体やプラグインのアップデートができていなかったということがなくなる。

 ただし、SaaS型サービスを利用するからといって、セキュリティ対策が不要というわけではない。このようなSaaSなどのクラウドサービスを利用する際に押さえておきたいのが、責任分界点と責任共有モデルという考えだ。

 責任分界点とはSaaSをはじめとするクラウドサービスにおける責任範囲の境界のことだ。上述したとおり、クラウドサービスは事業者がサービス品質を担保するが、それを実質的に運用するのはユーザー自身である。そのため、責任分界点に基づき、双方が責任を負うことになる。こうした考え方を「責任共有モデル」と呼ぶ。

 例えば、SaaS型ツールを利用するとしても、アカウント情報の管理は必要だ。また、ツール上にアップロードするファイルや情報についても適切に管理する必要がある。仮に個人情報を含んだファイルをアップロードすれば、漏えいリスクが伴うからだ。こうしたツールを利用する際は、ツール側の責任範囲やSLA(Service Level Agreement:サービス品質保証)などについて事前に確認しておきたい。

 最後に、最近ではSSG(Static Site Generator)と呼ばれるツールも登場している。このツールの場合、リクエストごとにページを生成するWordPressのようなCMSと異なり、静的なHTMLをデプロイする仕組みとなっている。レスポンスも迅速で、先述のようなCMS独特の危険性も少ない。こういったツールも含めて選択肢として考えてみるのもいいだろう。

 世界情勢の変化なども受け、今後もサイバー攻撃が激化することは確実視されている。すなわち、ウェブサイトへの攻撃リスクも増大することが見込まれ、WordPressを利用したウェブサイトへの攻撃もさらに増加していく可能性がある。こうした状況を踏まえ、WordPressやプラグインを適切に管理することが難しければ、今回挙げた代替の選択肢も検討することを視野に入れてほしい。

ウェブサイトの運営で必要なセキュリティ対策とは?
https://eset-info.canon-its.jp/malware_info/special/detail/210511.html

カテゴリートップへ