WordPressプラグイン「Easy FancyBox」の脆弱性

実は、私が以前から気になっていた事があります。
今年の2月から、WordPressの人気プラグイン「FancyBox for WordPress」の脆弱性が狙われ、Webサイトがイスラム国を名乗るページに改竄される事件が多発していました。 👉 WordPress 用 FancyBox プラグインにおけるクロスサイトスクリプティングの脆弱性
最新バージョンでは、既に対策済みらしいのですが、当サイトで利用しているプラグイン「Easy FancyBox」は果たして大丈夫なのでしょうか!?

そこで、私はWordPressのフォーラムを調査しました。
以下に、それに関連するQ&Aを貼っておきます。
Google翻訳では訳せないため、一応、私なりに日本語へ訳してみました。
(間違ってるかもしれませんが)
とてもシンプルな回答ですが、とりあえず大丈夫みたいですね! (^_-)

なお、回答で言及された「二つのプラグインが共有」とは、「jQuery」の事を指しているのではないかと思われます。


https://wordpress.org/support/topic/general-question-about-security

Easy FancyBox
[resolved] General question about security (2 posts)

BackpackersUnion
Member
Posted 1 month ago #

Hi RavanH,

This is probably old news to you, but I wanted to ask if the code exploit found in the other plugin “FancyBox” is relevant to your plugin? I’m not sure if they’re related to each other in any other way except the name, but wanted to ask.

Thanks for all your great work and here’s a link to the article

Thanks again,
Carl

https://wordpress.org/plugins/easy-fancybox/



——————————————————————-

RavanH
Member
Plugin Author
Posted 1 month ago #

Hi, no. Although the two plugins share more than the name (the script is called fancybox), the exploit was plugin specific.

 

Easy FancyBox
[解決]セキュリティに関する一般的な質問(2記事)

BackpackersUnion
メンバー
一月前に投稿されました #

RavanH こんにちは

これは、あなたにとって古いニュースかもしれませんが、もし他のプラグン「FancyBox」で、そのコードの脆弱性が見つかったならば、あなたのプラグインと関連するのかを尋ねたい。
もし、それらがその名前を除き、他の何らかの方法でお互いに関連しているのかどうか、私はわかりませんが、お伺いしたいです。
あなたの全ての偉大な仕事に感謝し、そして、ここはその記事へのリンクです。

再度、感謝します。
カール

https://wordpress.org/plugins/easy-fancybox/

———————————————————————-
RavanH
メンバー
プラグインの作者
一月前に投稿されました #

こんにちわ、いいえ。
その名(スクリプトがfancyboxと呼ばれている)以上に二つのプラグインが共有するのですが、その脆弱性はプラグインの仕様でした。

 

* 4月23日 追記
本件に関しては、以下のリンクに示されたWordPressの新しいリリースにより、クロスサイトスクリプティングの脆弱性が改善され、セキュリティが更に強化されたようです。 (このサイトは、既に新バージョンに更新済みです)

WordPress 4.1.2 Security Release

なお、WordPressの新バージョンへの更新は急がれますが、代わりにWordPressやプラグインの動作に不具合が発生するかもしれません。

* 5月9日 追記
WordPress 4.2.2のリリースにより、WordPress 4.1.2/4.2/4.2.1に存在した脆弱性と大半のバグが修正されました。

マルチリンガルのプラグイン「Transposh」のDBを修正

このサイトは、とりあえず、多言語サイトに作りました。
しかし、日本語と英語以外の言語に切り換えた時、タイトルの表記で、私の名前の「千里」がSenriではなく、Chisatoになっていました。
ところが、HTMLのTITLEタグの変換はTranshposhの編集モードでは直せない仕様になっています。
そこで、今回この問題を解決するため、TransposhのDBを直接修正する事にしました。
テーブルの構造が意外と簡単だったので、容易に修正が出来ました。

※参考までに、修正方法を以下に示します。

(1) 念のため、DBのバックアップをとる必要があります。

(2) サーバーのphpMyAdminを起動
検索メニューより、Transhposhの翻訳テーブル「wpxxx_translations」から翻訳元のタイトル文を検索する。 ⇒ wpxxx_translations – Table Search

(3) 修正したいレコードを選択
修正したいレコードの「編集」ボタンをクリックする ⇒ wpxxx_translations – Table Editing

(4) 翻訳ワードを修正
フィールド「translated text」を修正する ⇒ wpxxx_translations Table Editing 2-3

(5) DBの変更
「実行ボタン」をクリックし、DBを変更する ⇒ wpxxx_translations Table Modified

※4月12日 追記
無料版のgoogle翻訳エンジン「Google Translate API v1」のサービス終了に伴い、現在、Googleの翻訳機能が停止しています。
Transposh上で、これまで何となくGoogle翻訳が動いていたのが不思議ですが…
よって、Transposhの設定において、翻訳エンジンを「Microsoft Translator API」をサポートする「Bing」に設定しています。

実は以下のFAQで解った事ですが、タイトルタグの変換はページの最後のところで編集出来ました。 
無理にDBを修正する必要はないようです。 (m_m)

http://transposh.org/ja/faq/ ⇒ 「タイトルタグを翻訳したい (または他の任意のメタタグ)」

※8月26日 追記
Transposh Translation Filter バージョン0.9.7.2において、Googleの翻訳機能が復活していますので、現在、このサイトは、翻訳エンジンを「Google」に設定しています。

悪質なBOTからのアクセスを制限

 

Mission Impossible     

* このページは、常時更新中です。

本サイトに設置したPerlのアクセス解析プログラムのログとWordPressのプラグイン「NewStatPress」の分析結果を調査しました。
その結果、相変わらず、自身をBOTと名乗らない迷惑BOTから大量のアクセスがある事が確認できました。

そのBOTについてですが、当サイトでは以下のような種類を確認しています。

(1) 手当たり次第に掲示板やコメントフィールドへ商品の宣伝を書き込む「SPAM・BOT」
⇒ “Google No CAPTCHA reCAPTCHA”により、全てガードされています。

(2) WordPressへのログインを試みる「ハッキングBOT」(Brute Force Attack)
⇒ “Google No CAPTCHA reCAPTCHA”により、全てガードされていますし、更に、強固なパスワードに変更していますので、まず大丈夫でしょう。

* 4月20日 追記
その後、更にログ解析を進めた結果、ログイン名とパスワードをWordPressのxmlrpc.phpへ送信する方法で、裏口からの侵入を試みる多数のハッキングサイトを確認しました。 因って、そのIPアドレスを本日ブロックしました。

(3) プラグインの脆弱性を利用し、記事の書き換えを試みる「ハッキングBOT」
⇒ 当該プラグインは当サイトでは使用していません。なお、当サイトでは、プラグイン「Revslider」等へのアタックを確認しています。 ⇒ wp-config.phpを閲覧することで、彼らはDBやWebサイトへの侵入を企んでいます。

これらのアタックサイトに関しては、Windows XPやWindows 2000等のセキュリティが脆弱なPCやWebサイトがウィルスに感染し、それを踏み台にして邪悪なBOTへと変貌している可能性が考えられます。

上記の調査結果を踏まえ、これ以上、悪質なBOTの行為を許す事が出来なくなりましたので、この度、特に悪質なBOTへの大規模なアクセス制限を実施しました。

以下は、Apacheの「.htaccess」に追記した当サーバーへのアクセス拒否設定の一部です。
* 10月1日時点において、合計で302個のIPアドレスを昇順に定義しています。

 

これで、BOTで賑わっていた当サイトがかなり静かになりました。 (笑)

【アクセス制限について】
アクセス解析の結果、ApacheによるIPアドレスからホスト名への逆引きが不可能なケースを散見しましたので、ホスト名ではなく、全てIPアドレスの記述により、アクセス制限を実施しました。
例として、以下のように複数のIPアドレスを使って攻撃してくるBOTについては、IPのサブネットマスクを指定する事で対象IPを纏めて拒否するよう設定しました。

 

【サブネットマスクの指定方法について】
これ以降、情報処理技術者の方は読み飛ばして下さって結構です。
迷惑BOTの疑いのあるホスト名またはIPアドレスを以下のwhoisデータベースのサイトで、サーバー情報を取得します。

https://www.cman.jp/network/support/ip.html

実例として、「195.154.188.41」を検索します。
その結果、以下のように当該ネットワークが使用するIPアドレスの範囲が確認出来ます。

inetnum: 195.154.128.0 – 195.154.255.255

これを二進数に展開します。

11000011 10011010 10000000 10000000
11000011 10011010 10000000 10000001
11000011 10011010 10000000 10000010
11000011 10011010 10000000 10000011



11000011 10011010 11111111 11111110
11000011 10011010 11111111 11111111

これで、上位17bitが固定で、下位15bitが可変である事が解ります。
よって、上位17bitを固定するためのサブネットマスクは、以下のように表記出来ます。

11111111 11111111 10000000 00000000

対象IPアドレスに対し、このサブネットマスクと二進数の論理積の演算結果の値が一致すれば、制限IPアドレスという事になります。
このサブネットマスクは、「.htaccess」の中で以下のように記述します。

195.154.0.0/17
または
195.154.0.0/255.255.128.0

未だ全てのBOTを排除していないので、小さなBOTは居ますが、以前よりはかなり静かになった感じがします。
以下は、BOTへのアクセス制限を行った後におけるPerlのアクセス解析プログラムのモニター画面です。

*4月9日 追記
念のため、ログイン画面への総当たり攻撃を防御するためのプラグイン「Jetpack-Protect」も本日有効にしておきました。

*4月17日 追記
不正ログインをチェックするために開発された日本製のプラグイン「Crazy Bone」をインストールしました。

*9月18日 追記
先日、韓国からのDOSアタックやウクライナからのSPAMアタックを受け、サーバがダウンしたため、「.htaccess」を更新しました。以下の記述はその一部です。

なお、robots.txtにおいても、以下のように迷惑BOTからのアクセスを拒否しています。
因みに、SteelerとShim-Crawlerは、東京大学の研究室から来るクローラです。

 

*9月26日 追記
アクセスログの解析から、WordPressのピングバック機能を利用したDDOS攻撃の形跡も確認しましたので、本サイトのピングバック機能を無効に設定しました。
参考記事は、こちら ⇒ 注意喚起:WordPressの機能を悪用したDDoS攻撃対策のお願い

プラグイン「Disable XML-RPC Pingback」をインストールする事でピングバック機能を無効にし、更に、「.htaccess」に以下の定義を追加し、リモート投稿プログラム「xmlrpc.php」へのアクセスも禁止に設定しました。

NewStatPressの訪問者総数を補正(WordPressのプラグイン修正)

本サイトでは、WordPressのプラグイン「NewStatPress」を使用し、サイトのアクセス解析を行うと同時にサイドバーのウィジェットに閲覧ページ数や訪問者数を表示しています。

ところが、このNewStatPressのプログラムを解析したところ、DBに蓄積したデータが増えるに従い、ウィジェットの表示が遅くなる事が分かりました。
どうやら、サイトのパフォーマンスを維持するためには、NewStatPressが使用するデータベースに溜まったデータを定期的にリフレッシュする必要があるようです。

しかし、DBのデータをクリアすると、NewStatPressが表示するカウンタもリセットされる仕様になっているため、この処理を容易に行う事が出来ません。 👉 この現象は、バグであったように思われます。 (5月16日更新) Look at [resolved] access number automatically reset everyday (4 posts)

よって、やりたくは無かったのですが、最終手段として、NewStatPressのプログラムを修正する事にしました。
ネットを検索した限りでは、NewStatPressの最新バージョン(0.9.7)に対し、日本でこの修正を行った人は未だ居ない模様です。
修正箇所を見つけるのに少し時間が掛かりましたが、やっと見つけました。

本サイトは、1月15日から3月14日までに、7400人の訪問がありましたが、翌日にDBのデータをクリアした事で、カウンタが0になってしまいましたので、訪問者総数に+7400を加えるようプログラムを修正しました。

参考のため、修正方法を以下に示します。
なお、この処理で何らかの問題が生じても、私は一切責任を負いません。
もし、あなたがこれを参考にプログラムを修正されるのなら、あくまでも自己責任でお願いします。

以下に示すAjaxを制御するモジュールから呼ばれるAPI(variables.php)を修正します。
中身は、殆どSQLの集まりですが…

*Ajaxとは…

 

このプログラムの「Line 71」を以下のように修正します。(本サイトでは、+ 7400)

 

以下にプログラムの修正前と修正後のウィジェットの表示結果を示します。

* 8月11日 追記
因みに、私はNewStatPressのDBの肥大化を防ぐため、集計期間を3ヶ月に設定し、総合カウンタの集計については、NewStatPressのカウンタ値を使用せずに、Perlのプログラムの集計値を使用するようにしました。
(front-page.php内から、Perlのプログラム呼び出し)

NewStatPressに騙されました。 orz

アクセス解析のプラグイン「NewStatPress」のログは、膨大な量のデータが毎日DBに書き込まれます。
これを放置しておくと、サーバー資源を浪費するばかりなので、お掃除をした方が良いと思い、NewStatPressの設定を変更しました。
以下の設定画面の「Data purge」で「3 months」を選択し、設定を更新したところ、全ての統計データが消えてしまいましたぁ(T.T)
つまり、直近の3ヶ月分のデータを残し、古いデータを消すという仕様では無く、集計開始から3ヶ月経過したら全てのデータを消し、最初から集計をやり直すという仕様だった訳です。
せめて、訪問者総数のデータくらいは残しておけよコラ(–#)
と思ったんですが、もう後の祭りですよね。
ここは、Never以外の選択をしてはいけないところだった訳です。 (__;)

どうもWordPressのアクセス解析系のプラグインって、ユーザーへの配慮が足りないような気がします。

失った3ヶ月分のカウンターのデータ(visitor 7400)は、newstatpress.phpのプログラムを修正すれば、なんとか誤魔化せるかもしれませんが、後々のプラグイン更新が忙しくなりそうなので、止めて置きます。
また、1から出直します。
なお、perlで作られたグラフィックカウンターのCGIプログラムは健在なので、それで良しという事で素直に諦めます。 (–;)

※4月2日 追記
結局、NewStatPressのプログラムを修正しました。
詳細は、こちらを参照してください⇒ NewStatPressの訪問者総数を補正(WordPressのプラグイン修正)

※5月16日 更新
その後、NewStatPressの最新バージョンで、Data Purgeの設定を一ヶ月に設定し、DBをクリアしたところ、一ヶ月間のデータを残し、カウンタ値も保存されました。 カウンター値が0になる現象は、単なるバグだったようです。 orz

👉 Look at [resolved] access number automatically reset everyday (4 posts)

※9月26日 追記
Data Purgeの設定で、「Never」以外の値を指定した場合、カウンタ値は、その期間のデータのみが集計されます。 (プログラム解析により判明)
よって、総合カウンタは保存されませんので、ご注意下さい。
因みに、私はNewStatPressのDBの肥大化を防ぐため、集計期間を3ヶ月に設定し、総合カウンタの集計については、NewStatPressのカウンタ値を使用せずに、Perlのプログラムの集計値を使用するようにしました。
カウンタ管理に関しては、こちらの関連記事もご覧下さい。👉 ガラケー対応とシステムの改修

WordPressマルチリンガルサイトの推奨プラグインを全解説!

去年の暮れにサーバーを移転して以来、今年の初頭より、約2ヶ月の開発期間を設け、空いた時間に、WordPressのプラグインであるTransPoshをベースとしたマルチリンガルサイトとして、このサイトの構築を日々行ってきました。

今回の開発では、WordPressのUIの改善とシステム管理に力点を置いています。
未だ若干の不満が残っていますが、一応、今月末をもって開発完了とし、今後はコンテンツの拡充に努めたいと思います。

開発完了報告として、このサイトで導入したWordPressの推奨プラグインの全てを写真付きの解説で、時系列で以下に纏めます。

[ 2015年の2月16日までに追加した機能 ]

1. UI関連
(1) カレンダー表示
営業日と休日、イベント開催日を表示するカレンダーをサイドバーに設置しました。
プラグイン「Biz Calendar」の導入で実現しています。
Biz Calendarは、日本のプラグインです。 非常にシンプルで使い易いです。
私は、PHPで書かれたこのプラグインのCSS定義を修正する事で、カレンダーの外観をカスタマイズしました。

 

(2) マルチリンガルのサポート
当サイトを多言語で表示させるためのプラグイン「Transposh」を導入しました。
サイドバーから、表示言語を切り換えることが出来ます。
自動翻訳エンジン関しては、初期設定でGoogleかBingを選べます。本サイトでは、Googleに設定されています。 *
その自動翻訳の精度は、使えるレベルではありませんが、Transposhの導入で、サイトのマルチリンガル化をスマートに実現出来ます。
このプラグインは、手軽には使えますが、日本語の年月日などにおかしな変換が発生しますので、公式なマルチリンガルサイトには使えないと思います。
なお、Transposhのプラグイン設定「Settings」タブの中の「General Settings」で「Rewrite URLs」のチェックを入れてはいけないようです。このパーマリンク設定にした場合、デフォルトの言語以外のページ内の外部サイトへのリンクが正常に機能しなくなります。

* 5月8日追記: 現在、Googleの自動翻訳が機能しないため、一時的にBingに設定しました。
* 6月5日追記: Transposh「バージョン 0.9.7.0」のリリースで Googleの翻訳機能が復活しています。
* 2016年9月10日追記: 現在このプラグインは正常動作しないため推奨できません。最も推奨されるプラグインは、Polylangです。⇒ WordPressプラグインPolylangによるクラブフェリスWebサイトの多言語化

 

(3) コンタクトフォームの設置
Googleの「No CAPTCHA reCAPTCHA」に対応するコンタクトフォームです。
プラグイン「Contact Form 7」、「Really Simple CAPTCHA」、「WordPress ReCaptcha Integration」の導入で実現しています。

 

(4) ゲストブックの設置
Googleの「reCAPTCHA」に対応するゲストブックです。
プラグイン「DMSGuestbook」の導入で実現しています。

 

(5) サイトマップ
Topメニューに「サイトマップ」のメニューを追加しました。
プラグイン「PS Auto Sitemap」の導入で実現しています。

 

2. SPAM対策
(1) Akismet
WordPressに標準で搭載されたSPAM対策用のプラグインです。
このプラグインにより、大概のSPAM投稿が捕捉されます。

 

(2) Google No CAPTCHA reCAPTCHA
「No CAPTCHA reCAPTCHA」は、Googleが開発した人間かロボットかを判別する最新のAPIであり、SAPM投稿を元から排除するためのメカニズムです。
これは、Akismetで捕捉しきれないSAPM投稿や、SPAMロボットからの投稿なのか、人間の投稿なのかを判断するのが困難な投稿に対し、抑止効果を発揮します。
プラグイン「Google Captcha (reCAPTCHA) by BestWebSoft」の導入で実現しています。 ※

No CAPTCHA reCAPTCHA (Google Chrome)

No CAPTCHA reCAPTCHA (Google Chrome)

※10月13日 追記
このプラグインは、色々と問題が生じたため、現在、代わりのプラグイン「WordPress ReCaptcha Integration」を使用しています。
*WordPress Forums › Support » Reviews ⇒ Doesn’t work in login form

 

3. 統計情報

(1) NewStatPress
サイドバーのサイト統計情報をプラグイン「NewStatPress」を使って表示させています。 統計情報の詳細は、サイト管理者の管理画面から見る事が出来ます。
なお、NewStatPressのData Purgeの設定において、「Never」以外を指定すると、集計開始から指定された期限に達した時点で全ての統計情報が削除され、再度、集計開始の状態となってしまいますので、十分ご注意下さい。
私はこの設定で一度失敗していますから。 (笑) *

* 5月8日 追記: その後、NewStatPressの最新バージョンで、Data Purgeの設定を一ヶ月に設定し、DBをクリアしたところ、一ヶ月間のデータを残し、カウンタ値も保存されました。 カウンター値が0になる現象は、単なるバグだったようです。 orz
👉 Look at [resolved] access number automatically reset everyday (4 posts)

* 7月30日 追記
Data Purgeの設定で、「Never」以外の値を指定した場合、カウンタ値は、その期間のデータのみが集計されます。
よって、総合カウンタは保存されませんので、ご注意下さい。
因みに、私はNewStatPressのDBの肥大化を防ぐため、集計期間を3ヶ月に設定し、総合カウンタの集計については、NewStatPressのカウンタ値を使用せずに、Perlのプログラムの集計値を使用するようにしました。
カウンタ管理に関しては、こちらの関連記事もご覧下さい。👉 ガラケー対応とシステムの改修

 

(2) Jetpack
プラグイン「Jetpack by WordPress.com」のWordPress.com 統計情報より、シンプルなサイト統計情報を管理画面から見る事が出来ます。
Jetpackの利用で、ブログを WordPress.com アカウントと連携させ、各種の便利な機能を利用できます。

※10月14日 追記
私は、「サイト統計情報」、「シングルサインオン」、「グラバターホバーカード」 、「パブリサイズ共有」、「Protect」、「購読」 、「モニター」の機能を使用しています。
なお、「Photon」を有効にすると、プラグイン「EasyFancyBox 」が無効となるため、「Photon」は無効にしています。

 

(続きを読む…)

Web翻訳が滅茶苦茶な件 (Matter on incoherent Web translation)

 

Transposh1 Transposh2

当初は、当サイトをバイリンガル対応にするため、日本語に加え、英語の文章も貼り付けるようにしていましたが、段々と面倒になったので、WordPressのプラグインの一つ、”Transposh(http://transposh.org)”のウィジェットに翻訳を任せました。しかし、それは安易な考えだったようです。
試しにですが、”select language”のリストBOXから英語を選びますと、google翻訳(default)により以下のように表示されます。

Initially , in order to this site to bilingual , in addition to Japanese , English sentences also had to make paste , but it became so increasingly cumbersome , one of the WordPress plug -ins , “Transposh (http : the widget //transposh.org) ” I leave the translation. However , it seems it was a simplistic idea .
Try it in , but if you select the English from the list BOX of “select language”, by google translate (default) it will be displayed as follows .

なんだか意味不明の翻訳内容に…
どうやら、複雑な日本語の翻訳は難しいようです。(以下は、修正文)
でも、難しい日本語を書かなければ、それなりに翻訳されます。後半の文章はそのまま引用しています。

Though I was also pasting English text in addition to Japanese to adapt for bilingual for this site at first, I left the Widget of “Transposh”(http://transposh.org) that is one of plug-in for WordPress to translate because of becoming troublesome increasingly.
But, it seemed it was a simplistic idea.
Try it in, but if you select the English from the list BOX of “select language”, by google translate (default) it will be displayed as follows.

参考までに、他の翻訳例も挙げておきますね。

(続きを読む…)