WordPress によるサイト制作において想定すべきリスクをお教え願います。


長くウェブ制作の仕事をしております。
現在までの私の仕事は、下記のような単純なものです。

・成果物の多くは、HTML/CSS ファイル
・ドメインやレンタルサーバの基本的な処置や設定はする
・もっと高級な仕事は、なじみの個人や業者に外注する

しかし最近、仕事の幅を広げたいと思い、
今さらながら、WordPress(以下 “WP”)による制作を
加えたく思います。

しかしネットでは、下記のような趣旨の記述が見られます。

“WP(などの CMS)によるサイトは、
HTML ファイルベースのサイトよりも、
セキュリティ上のリスクが非常に高い”

そこで、下記の通り質問申し上げます。

WP で制作するにあたり、プロとして注意すべきリスクとしては
(特に HTML ファイルベースの場合と比較した場合に)
どのようなものがあるしょうか?

なお、この質問は、知っておくべきリスクを網羅するためもので、
解らない事項については、後日、個別に質問するつもりです。

ので、一つの事項を詳細にお教え頂くよりも、
複数の事項を列挙していただくほうが有り難く思います。

回答の条件
  • 1人1回まで
  • 登録:
  • 終了:2016/03/10 13:42:46
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:kotaeru3 No.1

回答回数40ベストアンサー獲得回数7

ポイント300pt

最近、趣味でjoomlaからwordpressに乗り換えた者です。
仕事ではjoomlaを使っています。

レンタルサーバに普通にインストールして、
1ヵ月で放置しておいたら、
コメントに書かれたコードから管理者を追加されました。驚
もう一つトリガーがありましたが、そんなセキュリティーホールがある
CMSってどうなの?と思いました。

セキュリティーを上げるプラグインを入れなかった私が悪いのかもしれませんが、
この仕様は無いなと思いました。

つまり、初心者の発注者が編集したり、
複数者での編集・コメント・掲示板などのシステムを考慮しなければ、
静的なものをお勧めします。
勝手に編集されるリスクが無いので。苦笑

ご自身のお客様が何をされたくて、
お客様に何を提供したいのか。
自分をどの方向に持っていくか
そこが重要なのではないでしょうか?

自分がやっておいて、なんですが
私的には今更、みんなが使えるwordpressに手を出すのも、、、

CMSを使うと管理する作業が増えます。
http://notnil-creative.com/blog/archives/3362

そのおかげで、お客様との接触機会が増えますが、
そこを手間と考えるかどうか、、、

クリエイティブな作業である静的なHTMLで
お客様を満足させるスキルがあるのであれば、
CMSの管理という面倒な作業は、
やりたくないことは、やらないほうがいいのかなと。
思った次第です。笑

id:tinyundertaker

初めまして。
「仕事では……」との事ですが、ウェブ制作がお仕事でいらっしゃるのでしょうか?

そして、攻撃者が、WordPress のコメント欄に特定の文字列を書き込んで、
管理者に自らを追加した、というお話でしょうか。
何とも……、恐ろしい話ですね。
もし仕事で作ったものにそんな穴があったらと思うと、ゾッとします。

「その種の」セキュリティホールがあるとすれば、
下記のお話は、「ウェブ制作者が仕事で WordPress のシステムを提供する」
ということの持つ、大変なジレンマを示していますね。

> 初心者の発注者が編集したり、
> 複数者での編集・コメント・掲示板などのシステムを考慮しなければ、
> 静的なものをお勧めします。
> 勝手に編集されるリスクが無いので。

何しろ、あくまでも「制作者はプロ、発注者はそうではない」わけですものね。

なお、お示しの URL は、近い将来の私には大変有益だと思いますが、
今の私には、「CMS 的用語」が多すぎ、やや理解が追いつきません。
将来ぜひ参考にさせていただきたいと思います。

> […]今更、みんなが使えるwordpressに手を出すのも、、、

> CMSを使うと管理する作業が増えます。
> […]
> クリエイティブな作業である静的なHTMLで
> お客様を満足させるスキルがあるのであれば、
> CMSの管理という面倒な作業は、
> やりたくないことは、やらないほうがいいのかなと。

なるほど、そういう考え方もありますね。お説自体には納得です。

ただし、まずは、一つくらいは、作ってみないといけないかもしれません。
CMS を仕事のバリエーションとして加えるにせよそうしないにせよ、
一つは作ってみてから決めないと、自分の方向性に自信が持てませんし、
そもそも「ウェブ制作者なのに WordPress のシステムに触れたこともないの?」
という話にもなってしまうでしょうから。

「仕事では joomla」とおっしゃっていますが、
こちらにはセキュリティホールは少ないのでしょうか?

何にせよ、kotaeru3 様のご回答によって、私の考え方は大きく変化しました。
大変ありがとうございました。

2016/03/08 06:50:57
  • id:fiwa
    とりあえず人気のあるCMSは攻撃者に狙われやすい、ということがいちばんの問題だと思いますが。
    http://www.jpcert.or.jp/magazine/acreport-cms.html

    あとは詳しい人プリーズ。
  • id:tinyundertaker
    tinyundertaker 2016/03/05 23:53:21
    id:fiwa 様、はじめまして。
    ナンパ師でいらっしゃるのですか?(笑) ご鞭撻を頂戴したいものです。

    人気と被攻撃率は比例するでしょうから、単純な言い方をすれば、「それ自体は仕方がない」ですね。

    しかし、お示しくださった URL を拝見したところ、
    ああ、例えばこんな方法で攻撃されるのだな、と解りました。
    こういうメソッドをいろいろ調査・収集しておいて、サイト制作の都度、対策を講じるべきですね。

    なお、お示しの URL にあった事例ですが、

    “改ざんされた PHP ファイルに、不正なコードが潜在しており、
    それがブラウザ上で iflame 等のタグを生成し、
    そのタグにプログラムされた挙動の結果として、
    本来のウェブページが乗っ取られ、閲覧者はそのページを見ただけで被害を受ける”

    という主旨だと思いますが、

    なぜサイトのアドミニストレータが「改ざんされた PHP ファイル」を使用してしまうのか
    わかりませんでした。

    想像ですが、ネットで拾ってきたものを不用意に使ってしまう、ということなのでしょうか……?

    当該 URL のページには、対策として、

    “CMS やそのプラグインを常に最新版にアップデートする、
    CMS (WordPress、Joomla!、Drupal、MODX など)によって不正なコードの位置が違うので、
    その違いを把握して確認を怠らない、
    CMS 利用時に限らず、サイトにかかわるソフトのアップデートやパスワード管理を適切に行う”

    などが挙げられていました。

    とても参考になりましたので、ぜひ、回答欄に転記いただけませんか?

    ありがとうございました。
  • id:fiwa
    不正なコードを挿入される主な原因はWordPressの脆弱性の放置とか不適切なパスワードの使用などからアクセス権を奪われてコードの書き換えを許してしまう、というものが多いと思いますが、攻撃のされかたは非常に様々なパターンがあり常に新しいものが出てくるのでイタチごっこみたいな面があります。上で紹介した記事は最近のケースなので、具体的にどういった経路から改ざんを許しているのかまだはっきりとはしていないのだと思います。
    一般的な対策はこういったところにも出ていますので参考にどうぞ。
    https://wpdocs.osdn.jp/WordPress_%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%82%92%E9%AB%98%E3%82%81%E3%82%8B

    私はどうもWordPressについての質問と相性が悪く回答してもだいたいロクなことにならないので、このへんで失礼します。
  • id:tinyundertaker
    tinyundertaker 2016/03/07 23:36:45
    id:fiwa 様

    なるほど。

    お示しいただいたリンク先は、この質問への返答の中でも、において最重要の参照先ですね。
    ありがとうございます。

    リンク先の下記の記述には、確かに。と思いました。
    オープン的な要素のあるネットワークではどうしてもこうなるのでしょうね。

    「セキュリティとは「完璧に安全なシステム」のことではありません。そのようなものは実用的ではないか、見つけたり運用したりするのは不可能といえるでしょう」

    「セキュアなサーバーは、サーバー管理者のコントロールのもとに、リソースのプライバシー・整合性・可用性を保護するものです」

    で、挙げてくださった具体的な問題をまとめてみますと――

    1)そもそも公式のコードに脆弱性が含まれる。しかも、その対処までのタイムラグが長い
    2)ユーザーのパスワード関係の設定・管理が不適切
    3)際限のないイタチごっこである

    (1) はともかくとして、
    (2) については、管理者側でパスワードの要件を厳しくするしかないわけですが、
    そうすると、ユーザー側の不便さと相反しますね。これは最大にして解決不可能な問題ですね。

    大変ありがとうございます。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません