先日、「Yuriko.Net」さんよりピンバックを頂戴致しました。
- ピンバック送信元
- SOMY 製プラグインはインストール禁止 ＠ Yuriko.Net
- 関連記事
- 【WordPress】Re: WP-SpamFreeが強力すぎる件（From: MMRT daily life）
相変わらずストレートな物言いでどきっとさせられるのですが、どうも、SOMY氏作のプラグインに、バックドアとなりかねないセキュリティ上のリスクがあったようです。
これまで、このブログでは「SOMY SpamBlock JP スパム対策プラグイン」を使用しており、また、別のプラグインにつきましても、このブログの前身のブログでは利用しておりました。
そのときは別に問題にもなっていなかったことですが、SOMY氏が活動を停止したあとの今になっての発覚に、驚かずにはいられません。
それにしても、プラグインそのもの以外の問題もあるとはいえ、あまりいい話ではありませんね。
プログラマは自分がメンテナンスできなくなったあとのことも考えてプログラムを書かなければならない。私は一応仕事でプログラムを書く身でありますので、私も肝に銘じておこうと思います。
なお、ピンバック受信後、私がWordPressで運営している2つのブログ（ここと「週刊 e217.net」）から、「SOMY SpamBlock JP スパム対策プラグイン」を撤去したことは言うまでもありません。
このブログで関連すると思われる他の投稿
4個のコメント
今回はセキュリティー問題だけに、余計鋭い書き方となっています
以前から SOMY さんの作品は「コードの質がいまいち」と思っていて信用していなかったのですが、「それなりに動いているからいいか」と考えていました。しかし、軽微とは言え、セキュリティー欠陥が見付かってしまうと、残念ながら叩かざるを得なくなってしまいました……。
ただ、バージョンチェック機構を入れるという発想は先進的で、すばらしいことだとは思います。その実装が script 要素を使うという点がまずいんですよね……。fsockopen で HTTP プロトコルを喋る仕組みだったら問題なかったのに、と思います。
本当は、WordPress コミュニティー自体が、テーマ・プラグインのセキュリティーに注力してくれれば、わたしがネガティブキャンペーンを打つ必要もなくなるかとは思っています。
ゆりこさん、こんにちは。
PHPについては素人に毛が生えた程度（にもかかわらず仕事で使わざるを得ないとはね）の私としては、プログラムの中身ではなく出力結果がすべてなので、着眼点の良さなどには脱帽していたのですが、今回撤去することとなった「SOMY SpamBlock JP スパム対策プラグイン」については、せっかくのWordPress管理機能を使わず、PHPファイルを直接ユーザにいじらせているのはエレガントではないなぁとは感じていましたね。
逆に、HTTPプロトコルを喋らせるのがすべてのサーヴァで出来るかどうかという問題はあるかも知れませんね。
まあ、今ではAjaxを使ってXMLやJSONなどで通信するのが旬なのでしょうが、それでもセキュリティのリスクがあることに代わりはないですからねぇ…。
今回は貴重な情報ありがとうございました。
PHP というかウェブアプリ自体が、セキュアに作るのが困難になってきています。$_GET[] や $_POST[] の値をそのまま echo しちゃだめ、というのは初学者にとってはつらいでしょう……。
確かに SOMY さんの着想のよさはなかなかのものだと思います。2005年の時点でああいうものを作っておられたわけですから。2005年は、PHP のセキュリティー向上が叫ばれつつあったころなので、きっちり情報蒐集してない人だと、従来のスタイルで作ってしまって危険なままというのはありそうです。
設定に WordPress の管理パネルを使わないというのは、たぶん複雑になるからかもしれません。(もしくは WordPress 1.5 以前はプラグインで管理パネルが追加できなかったとか) 余談ですが、管理パネルを使っていても、設定値を wp_options テーブルに入れずテキストファイルに書いてしまうプラグインもあって、こちらもうーーん、と思います (Mobile Eye+ はそういう設計)。
イントラネットの中など、外部と通信するにはプロクシー経由じゃないといけない場合はつらそうです。AJAX だと、ブラウザーがうまいこと処理してくれるのでいいわけですが。AJAX がらみはまだまだ不勉強なので、今がんばっていきたいところです。
一応サニタイズ関数もあるのですが、こんなの言われなければ分からないと思いますね。関数名自体、分かってしまえばどうってことないものの、そこに至るまでの過程が…。
それ以上に、マルチバイト関数とそうでない関数が別々に用意されているというのがそもそもの混乱のもとかと。これのおかげで苦労させられた時期もあります。
あ、そういえば、私がWordPRessをまともに使い出したのは1.5からですので、それ以前のことはさっぱりでした。
確かにう～んではあるのですが、データベースが吹っ飛んでもファイルさえ無事なら設定が消えないという別のメリットもありますね（笑）。90年代のCGIスクリプトに熟知した人ならこうしたくもなりますね。
Windowsアプリでも、いまだにレジストリを使わずにiniファイルを使うアプリが多いと思われますが、下手に雑多な情報が入り込むデータベースなりレジストリなりに内容を保持しようとすると、そのアプリがいらなくなったときに単なるゴミと化すという問題は無視できませんね。
まあ、こっちもセキュリティのリスクはついて回りますね。結局単純に実装するだけだと、今回の問題と似たような問題に至るのは必然でしょうから、データの入り口と出口の双方に仕掛けをしないとダメかも知れませんね。