KAGOYAサーバー

晴れレンタルサーバーで「カゴヤサーバー」というところがある。
けっこう大きく有名なサーバーではないだろうか?
ここのサーバーで通常では考えられないような不具合がある。
それは、PHPで他人のPHPソースやCGIソース、public_htmlより上のディレクトリのファイル、.htaccessの中身、.htpasswdの中身、DBの自動バックアップファイルなど、全て閲覧することができてしまう。
PHPのソースを入手できるということは、KAGOYAのサービスでインストールすることができる「phpMyAdmin」のconfig.phpのソースも入手することができる。 その中にはDBサーバーへの接続ID、パスワード情報が記述されている。
それでDBにログインすることが出来てしまうので、個人情報を登録してあるサイト(EC CUBEとか)だとあっさり情報が流出してしまう。 当然テーブルの削除も自由自在。
CGIのソースが見られてしまうということは、掲示板などのCGIのパスワードももちろん入手可能。 勝手に人の記事を削除したりすることができる。
さらにパーミッションが777や707のディレクトリのファイルの削除は自由自在。 先ほどの掲示板のログファイルとかも勝手に削除できる。 もちろん勝手にファイルを追加することも出来る。 1GBのプランの人のパーミッションが777か707のフォルダ内に、100MBのファイルを10個作成することも可能。 こんなのはプログラムで一瞬でできてしまう。
PHPのfopen関数やcopy関数を使えばファイルをそのままコピーすることもできる。

通常見られてはいけない設定ファイルとかはpublic_htmlより上のディレクトリにおいて、ブラウザではアクセスできない領域なので、安全なはずなのだが、それさえも崩れる。
どこに置こうが、コピー・閲覧自由自在。

さらにサーバーのhttpd.confファイルやpasswdファイルまで見ることが出来る。 もうこのサーバーはメチャメチャとしか言いようがないね。 こんな仕様のサーバーでよく今まで無事だったのかがとても不思議。

さくらサーバー、チカッパ、ロリポップで同じことを試したけど、当然できなかった。 これが普通なのにね。

ネットワークなどの専門的知識もなく、簡単なPHPのみでこんなことができてしまうなんて、サーバーのセキュリティ管理が甘すぎるとしか言いようがない。
大きな被害が出る前に、対策してくれることを望む。

Smarty

晴れPHPのテンプレートエンジンSmartyではまった。
先日2.6.19がリリースされていたので、それを使ってみることに。

人のFTPからアップロードしてSmarty.class.phpを読み込ませるのに、ファイル名はFTP上のをコピーしてrequireした。
template_dirとcompile_dirを設定して、いざdisplay!

しかし……不思議なエラーが……
コンパイルできないみたいな文面だった。 しかしコンパイルするフォルダを指定されているしパーミッションも正しく設定されている。 なぜだ……
悩むこと10分…… ようやく原因がわかった。
FTPの設定だった。 アップロードしたファイルを強制的に小文字にする設定になっており、
Smarty.class.php
Smarty_Compiler.class.php
が小文字になってることが原因だった。 require.phpはFTP上でファイル名をコピーしたので問題はなかったのだが、内部で読み込むほうに問題があった…… しかしFTPにこんな設定があったとは… 人のFTPを使うときは注意しよう。
てっきり2.6.18から2.6.19に変えたのが原因かと思ってしまった。

multiple

HTMLのセレクトタグにmultiple属性をつけると、複数選択できるセレクトボックスを作ることが出来る。
複数選択できる状態でPHPにPOSTしたらどうなるのかやってみた。
そしたら、選択した最後の値のみ送信されてきた。
selectのname属性をname=”name[]”のように配列形式にして、複数選択して送信してみた。
そしたら配列で格納できた。

ふーん、こんな使い方ができるのか。 チェックボックスみたいな感覚だね。 覚えておこう。

ページ不具合

雨昨日PHP5.2.5にしてから、不具合が出てきた。
require_onceでhttp://から始まるファイルを指定していたら、エラーがでてしまった。
調べたら、allow_url_fopenをOnにすればいいと書いてあったのだが、phpinfoを見て見たらきちんとOnになっている。
さらに調べていたらallow_url_includeをOnにしないといけないらしい。
URL経由でファイルを取得してPHPとして実行するにはこちらをいじるんだって。
PHP5.2.0からの追加らしい。

とりあえず解決。

ブログスパム対策

雨のちくもり最近ブログにものすごい量のスパムコメントが届く。
Word Pressのスパムフィルターで表には出てこないのだが、「コメントがありましたメール」とスパムにひっかかったコメント一覧で削除しないといけないので面倒。

いっそのこと記録すらしないようにしようと対策をした。


wp-comments-post.phpに以下を追加した。
Array

たったこれだけで快適なブログライフになった。

それと今日PHP5.2.5に切り替えをしたのだが、ブログで使ってる作成中のアクセス解析でエラーがでていて1時間くらいブログが見れない状態に……
MySQLクラス部分のエラーだったけど、直すのがめんどいので、とりあえず切ちゃった。

JavaScriptのCookieとPHPのCookie

晴れ夜中に次女が大泣きで起きた…… ミルクをあげたら寝た……
Cookie Manager」というJavaScriptで簡単にCookieを扱うライブラリがある。
JavaScriptでクッキーを扱うのはなかなか面倒だ。 書き込みはいいけれど、読み込みがね…
全てのクッキーが連結された状態で1行で取得されるので、自分で分割して、検索して、必要な部分だけ引っ張る処理を加えないといけない。
それを簡単にやってくれるのがCookie Managerというライブラリ。

これをつかって、クッキーの書き込みや読み込みを簡単に行っていた。
しかし、PHP側でこのクッキーの値を処理して、使い終わったクッキーを削除する処理を加えたのだが、なぜだかクッキーの削除ができない。 削除だけでなく、PHPからは参照のみしかできない。 上書きもできない。

この問題にどっぷりはまった……
考えて考えて……考えて考えて……ようやく原因がわかった。
クッキーのパスの指定がいけないらしい。
Cookie Managerでは、「/」というパスで有効なCookieを作成する。 PHPではPHPファイルのあるディレクトリで有効なCookieを処理しようとする。(/livrersdream/js みたいな)
Cookieをセットするときに、パスも指定してあげて問題なくPHP側で削除もできるようになった。

いろいろネットを見ていたら、Cookieのパスはブラウザに依存するらしい? Firefox2でやっていたのだけど……
「/」の指定だったら、それ以下のディレクトリ全てに有効なCookieが作成されるんじゃないのかな?
まぁ使うディレクトリまで指定することで解決したからいいや。

XML_RPC

くもり最近仕事で、ブログに関することをやっていた。
どうやったらブログに外部から投稿できるのだろう?

いろいろ調べたら、ブログ側でAPIを用意していないとできないらしい。 それが「XML_RPC」というのが主流っぽい。
XML形式でブログの本文とかを作成して、それをサーバーにPOSTする。 すると見事に記事が投稿される! そんなすばらしいものだったのだが、使い方がさっぱり解らず。 XML_RPCについていろいろ調べた。
blogger XML-RPC API
metaWeblog XML-RPC API
mt.XML-RPC API
の3つがあった。 試しているのはgooブログ。
まだまだ手探り状態だけど、新規投稿とカテゴリの関連付けはできた。

もっと勉強しなくては。