そのラボにおける活動の第一弾として、『日本国内におけるWordPressセキュリティの現状』の分析レポートが公開されています。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いたラボが公開した分析レポートにおいて、WordPressへの攻撃（検出箇所）として以下のものが最多として書かれていましたのでご紹介します。

WordPressへの攻撃で最多のものとは

WordPressへの攻撃（検出箇所）で検出が最も多かったものは、『xmlrpc.php』というものです。

『XML-RPC』というのは、遠隔での呼出しを行うプロトコルの一種で、WordPressで言えば、通常の管理画面以外からの投稿を可能にするものです。

WordPressの場合、スマホアプリなどのXML-RPCを使った更新にも対応しているため、xmlrpc.phpというファイルが用意されています。

これが使用可能になっているとどうなるのか？

xmlrpc.phpをターゲットとしたDDoS攻撃などの被害に遭う可能性があり、それを受けた際にはサーバが高負荷状態でパンクしてしまうことにもなります。

つまり、アクセスできない状態にされてしまう恐れがあるということです。

では、これを避けるための対策法はどのようにすれば良いのか？

xmlrpc.phpファイルへの攻撃の対処法

WordPress3.5未満においては管理画面の投稿設定にxmlrpcを無効にするチェックボックスがあったのですが、WordPress3.5以降のバージョンではそれがなく（現在の最新は4.9.4）、デフォルトで有効な状態にあります。

その場合、一番簡単な方法は『.htaccess』でxmlrpc.phpへのアクセスを禁止してしまう方法です。

<Files xmlrpc.php>

Order allow,deny
Deny from all
</files>

と、記述を追加すればOKです。

どうしても特定のIPアドレスからのみ許可をしたい場合、

<Files xmlrpc.php>

Order allow,deny
Deny from all
Allow from xxx.xxx.xxx.xxx
</files>

と、赤字の部分を加えればOKです。

これ以外に、多少サーバへの負荷が残るものを考慮したいのであれば以下の方法が良いです。

<IfModule mod_rewrite.c>

RewriteEngine On
RewriteBase /
RewriteRule ^xmlrpc\.php$ “http\:\/\/0\.0\.0\.0\/” [R=301,L]
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

というように、WordPressで.htaccessに設定される記述に赤字の部分を追加し、xmlrpc.phpへのアクセスを0.0.0.0にリダイレクトさせてしまう方法もあります。

ちなみに、プラグインを使って無効化する方法もありますが、プラグインそのものに脆弱性が見つかることもあるためお勧めではありません。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

10月前半にサポートが終了したOffice 2007ですが、その時点では日本国内だけでも40万台以上のPCに利用されており、未だ相当数のPCで利用されていることが推察されます。

それを受けてか、Microsoft（マイクロソフト）が以前と同じような対応を行いました。

Office 2007の脆弱性修正パッチの提供

先月、Microsoftは10月にサポートが終了した『Office 2007』向けの脆弱性修正パッチを公開しました。

これは、Officeに付属する数式エディターに対する脆弱性修正プログラムで、脆弱性が悪用された場合、遠隔からPCを操作されてしまう可能性があるというものです。

この脆弱性修正パッチを提供せずに影響を回避する方法もありますが、レジストリに手を加えることになるため、基本的には脆弱性修正パッチを提供するべきです。

また、Office 2007を含め、以下のOfficeが数式エディターの脆弱性の影響を受けますので、早期にアップデートされることをお勧めします。

Office 2007 Service Pack 3

Office 2010 Service Pack 2（32bit/64bit）

Office 2013 Service Pack 1（32bit/64bit）

Office 2016（32bit/64bit）

以上、ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

ある方の記事で、要件定義にまつわる訴訟事例を拝見しました。

そこにあったのは、ベンダーには厳しいと思われる判決内容でした。

要件不備の責任を問われたベンダー

システム開発業者Aは、旅行会社Bの航空チケット発券システムを受託し、開発したが、システムの機能不足で稼働できず、訴訟になってしまったという話しで、その記事に書かれている機能不足とは、『遠隔地からデータベースを操作できる機能が不足していた』というもののようです。

この訴訟の結論を先に言うと、

要件の不備の責任の一端はベンダーにもある。

という判決で、

ベンダーは、ユーザーの業務をよく学び、実際のオペレーションを理解した上で、ユーザーが作成する要件定義書の過不足をチェックしなければならない。

という判断であったと、その方の記事には書かれています。

では、何故このような事態になってしまったのでしょうか？

要件定義の手順ミスの可能性

この訴訟、少々推察にはなってしまうものの、要件定義における手順にミスがあったと思えます。

まず、業務分析の段階において、システム開発の対象となるすべての部分を明示してもらうように促していない可能性があります。

次に、ユーザーが作成した要件定義書であれ、双方においてすべての要件に対して読み合わせと合意を行っていない可能性もあります。

これ、私であれば要件定義書に書かれている内容がすべてであることを明記し、読み合わせ後、合意した旨を責任者・担当者などに押印してもらいます。

（これを行っても解釈の疑義が生じることはあり得ます。）

要は、要件定義書に書かれている以上も以下もないということと、それに対してすべての関係者が合意したという証を残すということです。

もう1つ、ユーザーもベンダーが当然知っているだろうという勝手な思い込みは危険です。

要件定義書から漏れていることがあるならば、それはしっかり指摘をすべきではないでしょうか。

そういった漏れなどを無くすためにも要件定義を行っているわけですから。

ご参考までに。