「Web技術」タグアーカイブ

PHPの脆弱性、最重要チェック項目は3つ

セキュリティ(PHPの基礎体力)

PHPに限りませんが、CMSやCGIで大活躍のスクリプトは、扱いを間違えると大惨事になります。外部から乗っ取られ、サイトを改竄され、個人情報を盗まれ、犯罪に利用される。要するに家の鍵を開けたまま放置するようなものです。少し考えただけでもぞっとします。サイトの人気有無に関わらず、外部に露出しているスクリプトは、常にその危険に晒されていると思ってください。油断していると痛い目に遭います。

主な脆弱性について、上記ページが非常に読みやすく纏まってたので紹介します。例も交えて分かりやすいです。

脆弱性は3つ
register_globals = On の危険性(php)
GET・POST・COOKIEの汚染(SQLインジェクション、改竄)
クロスサイトスクリプティング(XSS)

少しでも気にとめていれば防げる事です。開発者の人はご注意を。

MODxをサブドメイン対応する方法

CMS(CMF)のMODxは、1つのスクリプトを共有して、複数のサイトを稼動させることが出来ません。そのため、修正をしない方法では、サブドメイン毎にMODxを設置するか、DBを共有したままプラグインによりスタートページを振り分けるもの(Subsites/subdomains 0.1)に留まっています。

それぞれ一長一短あります。前者はサブドメイン分のMODxを設置するため、リソース増加してしまいます。プラグインも共有出来ません。しかし、全てのリソースが分離されている分、メンテは容易です。後者は単一のMODxをおいて置けばいいのでリソースは少なくてすみます。反面、DBを共有しているので、ページ数が増えメンテが困難になります。また、閲覧者が適当なページIDをリクエストしたときに、隠しておきたいはずの他サブドメインページが表示されてしまう問題も残ります。

そこで私は第3の方法を提案したいと思います。物理的なファイルリソースを共有したまま、DBとキャッシュを分離する方法です。このケースで言うDBとは、コンテンツ、スニペット、プラグイン、MODxの設定です。

この方法はMODxのコアスクリプトを変更します。本体がバージョンアップした際には、私のリリースを待つか自分で再修正をするしかありません。その代わり、MODxコアをバージョンアップしない限り、あらゆる問題に対応できる利便性が売りです。

方法は至極単純、インストール時に出力されるconfig.inc.phpをサブドメインごとに分ければいいのです。ただし、これだけでは不十分で、不具合が多発します。というのも、cacheディレクトリの中身をMODxが頻繁に参照するからです。ここに、MODxの設定の一部もなぜか含まれています。生成されるキャッシュをそれぞれサブドメインごとに分別されるように修正してください。

そんなわけで、私が改造したMODxを公式にポストしておきました。

日本語サポートスレッド本サポートスレッドも活用してください。

Subsites the MAD [HACK] ver.2.0

ログ解析「Visitors」

1秒で10万行を処理するフリーの超高速なログ解析ソフト「Visitors」

Visitorsはapacheのログを僅か数秒で解析して表示してくれる、コマンドラインベースのプログラム。Graphvizを利用するとリファラーを利用して視覚的なユーザ追跡(Tracking)も可能。通常はCron tabで解析結果を自動出力することを想定していると思われます。

しかし、この解析速度であれば、日時範囲を指定してオプションを切り替えながら、ログを比較してみたいものです。使いやすいGUIフロントエンドはないでしょうかね?

ちなみに、これ、ソースコードで配布されてます。Windowsにはコンパイルしたお試し版がありますけど、完全版実行ファイルは有料サービスです。以下にVisual C++ 2005での修正個所を記しておきます。

#tail.c
#line3
- #include <unistd.h>
+ #include "unix2win.h"

#visitors.c
#line22
+ #include "unix2win.h"
unix2win.h
#ifdef WIN32
#define snprintf	_snprintf
#define vsnprintf	_vsnprintf
#define strcasecmp	strcmpi
#define strncasecmp	strnicmp
#define ssize_t	int
#define inline __inline
#include <io.h>
#define off_t _off_t
#define read _read
#endif

百度からのアクセスを制限する方法

Baiduspider(Wikipedia)

先月22日から2分に1回の頻度で、BaiduspiderというROBOTから絨毯爆撃が来ています。おかげでログがBaiduspiderの名前で埋まってしまいました。

このROBOT、どうやら中国"国内"限定の"百度"と言う検索エンジンのようです。中国国内ということは、幾ら百度の検索TOPになっても、我々日本人には恩恵が少ないと思われます。それよりも、このDOS攻撃に近い絨毯爆撃によるサーバ負荷のほうが遥かに問題。ご丁寧にも同じURLを何度もリクエストしてくる行儀の悪さです。

そこで、robots.txtで規制をする事にしました。まずは温厚に1時間1回のアクセスにしてもらうようお願い。

User-agent: baiduspider
Disallow:
Crawl-delay:3600

User-agentにはBaiduspider(最初大文字)やBaiduspider+(最後に+)を書くと認識してくれません。ログのUser-agentと認識名が違うところに悪意さえ感じてしまいます。

さて、この状態で20日経ちましたが、アクセス頻度が下がりません。更に問題なのが「Robots.txt」を読みに来ないこと!一体何ヶ月待てば設定が反映されるんでしょう。

どうしたものかと調べてみると、この百度のクローラーBaiduspiderは、巷でも評判が悪いらしい。先のWikipediaの記事でも、それが窺い知れると思います。

そこで、Robots.txtで一切拒否。サーバ側でも弾くようにしてしました。行儀が良くなってから開放する予定です。百度は今後日本にも進出するらしいですが、これでは先が思いやられますね。

User-agent: baiduspider
Disallow: /

その他、行儀が悪かった最近のROBOT。

  • BecomeBot←ショッピングリサーチ用
  • BecomeJPBot←上記日本語版

APNGとmPNG、混乱招く仕様乱立

先週、firefox nightly buildにAPNG(アニメーションPNG)のパッチが実装されたそうです。そこでAPNGについて調べてみました。

APNGとはMozillaグループが提唱するPNGのアニメーション規格。拡張チャンクによって実現されているそうです。しかし、機能拡張部分を公的なものにしないと、普及も見込めず将来的に問題が起こる可能性があります。MozillaグループはPNGグループに対して、この独自拡張を認めさせたいようです。

ここでPNGグループ側は猛反発します。元々PNGは1枚画像のための仕様。そこに無理にアニメーション拡張を付加するのは美しくない。議論を続けるうちにPNG側コミュニティでは代替案としてmPNG(モンタージュPNG)を出してきました。

mPNGは複数画像をタイル状に並べて1枚絵とする仕様。mPNGビューワで閲覧すると各タイルを一定時間ごとに切り替えて表示し、アニメーションを実現させるそうです。旧PNGビューワでは全フレームがサムネイル状に表示され、一応の後方互換が保証されます。

しかし、MNGがありながら今更アニメーション仕様を増やす意味があるのか?Mozilla側は2003年にMNGは仕様が複雑でライブラリ肥大化に繋がると言い、サポートを打ち切った経緯があります。肥大化を避けたいだけであれば、MNG-LCを採用すれば良かったのではないでしょうか。

私はAPNGもmPNGも反対です。仕様の乱立は避け、もっと議論すべきだと思う。