PHPﾀﾝ

電脳言語を嫁に例えると....

PHP

• 料理は大の得意なのだが、他の家事は大の苦手。他の嫁達に助けてもらう事もしばしば。
• そのせいか、他の嫁の夫達にかなり疎まれている。
• ときおり髪型もメイクも思い出したようにばっさりかえるので、夫も妻の顔が思い出せなくなることもしばしば。

ああ、それでもそれでも大好きだよPHPﾀﾝ。でも、最近はJavaScriptﾀﾝを２号さんにしてるおいらを笑って許してくれるおおらかなPHPﾀﾝに夢中！

おまけ：同じ所で見つけたデスマﾀﾝ。鬼。

今日のFlexyメモ

form要素周辺のマークアップの構造が正しくない（終端タグが抜けている、開始タグと終端タグの順序が親子関係にないなど）とFlexyは正しい階層構造にしようとおせっかいをして、勝手に<form>の後ろに</form>をつけform要素を閉じてしまう

このようになったときにはテンプレートの階層構造をチェックすること。

危険があることを理解していればそれは危険ではない

PHPパッチ、一部の脆弱性は未修正

PHPのアップデートで対処されたはずの脆弱性が、実は修正されていないことが分かったと、セキュリティ研究者が指摘した。

PHP開発チームは6月1日にアップデートバージョンの5.2.3をリリースし、複数の脆弱性に対処した。リリースノートによれば、この一環として「chunk_split()」の整数オーバーフローの脆弱性も修正されたはずだった。

しかしこれについて、PHPチームを脱退した研究者のステファン・エッサー氏が、自身の運営するPHPセキュリティブログで問題を指摘した。同氏によると「フィックスは壊れているばかりかまったく無意味」であり、PHP 5.2.3で整数オーバーフロー問題は未修正のまま、別の行に移されただけだという。

US-CERTも6月6日付で、PHP 5.2.3にはchunk_split()機能に整数オーバーフローの脆弱性が存在する可能性があると指摘。エッサー氏が掲載した情報を紹介している。

オープンソースのよいところはこういう風に世界中からツッコミが入ることによって信頼性を担保している点で、利用者は常に注意を払わなければいけないけれども、理解して使っているのならば問題はないだろう。こういう民主主義的なところは好きだな。

しかし、これでまたPHP5に移行しようという熱がちょっと冷やされたよ。

Return-Pathが指定できない！

mail関数の第４引数にReturn-Pathを入れても[e-mail]になるニダ！　かんしゃく起こる！！　てな訳でいろいろ検索したところ

bool mail ( string $to, string $subject, string $message [, string $additional_headers [, string $additional_parameters]] )

additional_parameters（オプション）

パラメータ additional_parameters は、 追加のパラメータをメール送信プログラムに渡す際に使用可能です。 メール送信プログラムは、設定オプション sendmail_path により設定されます。例えば、 sendmail を使用する際に -f オプションを使って エンベロープの sender アドレスを設定する際に使用できます。

なるほど。これで、

mb_send_mail($to, $subject, $body, $header, "-f [e-mail]");

とかして解決。

反日BLOG監視所のレイアウトが崩れる件

反日BLOG監視所のBLOGのレイアウトがFirefoxで見ると崩れる場合があるのだが、原因はGeckoエンジンのバグで、如何ともし難いらしい。なので、URLっぽい文字列をBLOGのコメント投稿時にa要素に置換して、幅を圧迫しないように修正する方針で対処します。

function url_auto_link($input_string) {
　preg_match_all("/(^|[^=\"'])(https?|ftp|news)
(:\/\/[[:alnum:]+$;?.%,!#~*\/:@&=_-]+)/
",$input_string,$out,PREG_SET_ORDER);
	for ($i=0;$i<count($out);$i++){
		$url_string = $out[$i][2] . $out[$i][3];
		
		$input_string = str_replace($url_string,"<a href=\"$url_string\" target=\"_blank\">
URL</a>",$input_string);
	}
	print $input_string;
}

こんな感じ。帰ったら実装予定。但し、既に投稿された分は対処できないと思います。いや、DBに格納されたコメントをいじれば出来るだろうけど、労力がね。

Smartyマニュアル

Smarty - コンパイリング PHP テンプレートエンジン

本家に日本語マニュアルが掲載されました。おいら的にはFlexyのほうが好きだけど、Smartyは反日BLOG監視所で使用しているXOOPSに使用されているので、離れることは出来ませんのう。

osCommerceのSEO対策

ちょっとメモ

• 検索エンジン対策(1)-product_info.php の改造-
• 検索エンジン対策(2)-default.php の改造-

うむ。一日あればなんとかなるレベル。

あるあるｗｗｗｗ

PHPとしたがPHPに限らず。

[プログラミング] Google Code Search で「とりあえず」を検索するとおもしろい

あるあるｗｗｗｗ　ということで先日納品した某サイトのソースをgrepしてみると･･･

orz.　ま、まあ直しちゃえばいいし。

どっちだよ

よくあるご質問（FAQ）

Q.Eメールで絵文字や半角カタカナは使えますか？

A.半角カナや絵文字についてはご利用いただけます。 Eメールで送っていただく際は文字化けの原因となりますので、お使いいただくことができません。ご注意ください。

使えるのか使えないのかはっきりしろよｗ

[PHP-users 31379] Re: メルマガ送信でソフトバンク特定機種の文字化け

今、ソフトバンクへ下記FAQページの意味を確認しました。

「半角カナや絵文字についてはご利用いただけます。 Eメールで送っていただく際は文字化けの原因となりますので、お使いいただくことができません。ご注意ください。」

この意味は、携帯からパソコンに絵文字を送信すると文字化けが起こりますという事のようです。

では、半角カナで文字化けはしますか？と聞いたところ「送信も受信も半角カナは利用できます」という回答です。

・・・もう少し、理解しやすい文章にしてほしいものですね。

ということらしいのですが、上記の意味をあの文章から読み取ることは無理ですよ。

array_mapの使用法

おいらは頭が悪いので今までarray_map()の使用法がマニュアルを見ただけでは理解できなかったのですがstripslashesの使用例を見て理解できました。

<?php
function stripslashes_deep($value)
{
   $value = is_array($value) ?
               array_map('stripslashes_deep', $value) :
               stripslashes($value);

   return $value;
}

// 例
$array = array("f\\'oo", "b\\'ar", array("fo\\'o", "b\\'ar"));
$array = stripslashes_deep($array);

// 出力
print_r($array);
?>

多重配列のパラメータ処理に威力を発揮しそうですね。つーか自分の頭の悪さに嫌気がさすな。

公開Proxyを弾く

DNS ブラックリストによる SPAM フィルタリング (2)

niku.2ch.netはものすごく使えるらしい。

checkdnsrr($ip.".niku.2ch.net.","A");

で汎用性が効きそうですね。

PEAR Mail_Queue不具合メモ

PEAR::Mail_Queueでバシバシメールをためて一気に送信とか試しているのだが、どうにもメール本文がおかしい。あれこれ検索してPEAR Mail_Queueの不都合にたどり着いたため、

/usr/local/lib/php/Mail/Queue/Body.php
    function getBody()
    {
        return stripslashes($this->body);
    }

を

    function getBody()
    {
        //return stripslashes($this->body);
        return $this->body;
    }

として解決。

メール受信時にphpを起動

#vi /etc/aliases
foo: "|php /home/foo/test.php"
#newaliases 

これだけだとsmrshに怒られてしまうときは、

# cd /etc/smrsh
# ls -la 
# ln -s /usr/local/bin/php ./php

で、標準入力に取り込み可能。

$stdin = fopen ('php://stdin' , 'r');
while (!feof ($stdin)){
//一行ずつ配列に格納
$buf[] = fgets($stdin, 4096);
}
fclose($stdin);

これでヘッダから一行ずつ配列に取り込まれる。

さらにサニタイズについての横着な結論

サニ

「サニタイズ」って単語自体一般的にはなじみの薄いものだし、ほんとはそれ以前の問題なのに、なんかそれ使えば「セキュリティに気をつけてますよ」的というかソレっぽいので使ってみたっつうか、いろんな人がいろんな意味で使ってるのでアレってのはそうね。

いろんな人がいろいろな意味で使うということはあまりないんじゃないのかなと。多くの人が「HTML特殊文字をエスケープすること＆SQLでシングルクォートをエスケープすること」として使っていると思います。ただ、それは普通に息を吸ったら吐くくらいの感覚で行うべきことですし、その自然な行為に「サニタイズ」という言葉をつけることの愚をキャンペーンしていると思っています。
まあ、ぶっちゃけていえば「サニタイズするからという名目で工数見積もるな」ということですな。

まーそもそも HTMLブラウザへの出力として変数入り "" 文字列を生の print() で吐いてること自体がアレで、アプリケーション本体から「HTMLを入力として受け付けるシステム」に出力を渡すときにちゃんとフィルターを通すというか helper()郡 なり out()なりを介在させるべきなんだろうね。SQL はよく知らんけど。

そういうことです。ただ、全部の箇所にhtmlspecialcharsって書くのは面倒である上に可視性が下がるので、そうしなくてもいい工夫をしようよとおいらは思っていて、全ての変数出力に対し自動的にhtmlspecialcharsしてくれるFlexyを使用するのが解決としてスマートかなと思っています。エスケープしたくないときの対処も楽ですし。

SQLはJavaでprepare使ったらもう楽で楽で。DB::prepare()を手放せないですねえ。

「サニタイズ言うな」キャンペーンの私の横着な解決

「サニタイズ言うなキャンペーン」私の解釈

孤高さんのところから手繰ったネタ。

高木氏の原文

ではなぜ、解説書でさえ(C)のようなコードを書いてしまうのか。3つ考えられる。1つ目は、貧民的プログラミングの発想。2つ目は、煩雑な見栄えを嫌がってということがあるだろう。

まず、「htmlspecialchars」という名前が長い。これをあちこちに埋め込まないといけない。文字列連結している文の部分部分に htmlspecialchars を入れて、入れて、入れていかないといけない。これが嫌で嫌で堪らないプログラマが、それでも「セキュリティ対策しないと……」ということで仕方なく必死に作業していくと、必要最小限の場所にだけ htmlspecialchars と書くことになりがちだ。

その結果として何が起きるかというと、いわゆる「サニタイズ漏れ」だ。それを目を皿にして探していく作業も、たいへんなコストがかかることになる。

上に挙げた(A)の事例について、こうした脆弱性を指摘された本の著者はこう反論するかもしれない。「PHPの入門書なので、まずは PHP による HTML formの基本的な書き方を説明したいだけ。最初からそこらじゅうに htmlspecialchars と散りばめたのでは、読者がついてこなくなってしまう。セキュリティ対策の方法は後半で書いているのだから、これでよいのだ……」と。

事実、2002年に、ある@ITの解説記事の脆弱性を指摘したとき、関係者の方から

記事の主旨はサーバサイドアプリケーションの諸環境の紹介を第一としておりますことご了解いただけますと幸いです

という釈明を受けたことがある。また同じころ、知人が書いていた書籍について、出版前に読んで欲しいと依頼されて読ませてもらったところ、やはり、 SQLの使い方を紹介する章のサンプルコードがモロにSQLインジェクション脆弱性のある安易な書き方になっていて、「こういう書き方、やめようよ」と言ったことがあるのだが、著者は、「ここはSQLの使い方をわかってもらうためだから余分なコードは入れたくない」と主張して、全面的な書き直しはしなかった（注意書きが添えられ、後ろの章にセキュリティ対策の章が付け加えることで対処された）ということがあった。

このように、コードの見た目が煩雑になることがプログラマ達に嫌われていて、特に解説本の著者がひどく嫌っていることがわかるが、それが脆弱プログラマを増殖させる原因となっている。

そして3つ目の原因が、「サニタイズ」という言葉が安易に流行りすぎていることの弊害である。

「サニタイズ」というのは、「無害化」という意味の言葉であることから明らかなように、あくまでも「セキュリティ対策」としての文脈でしか語られない。そうすると、「CGI入力の（に依存した）変数はサニタイズせよ」というスローガンになってしまう。これが悪しきプログラミングスタイルを助長して困る。

正しくは全ての変数をエスケープ対象とせよが基本であるし、変数だけじゃなくて式全体をエスケープの対象とするべきなのに、「サニタイズ」という言葉で教育が行われていると、その考え方に至る機会が殺がれてしまう。

だから、「サニタイズ言うな」なのだ。

なるほどと思う。まず大前提として、「セキュリティ意識の低いプログラマ」というものを大量生産している背景には「サニタイズ」という言葉で「ごく普通のセキュリティ対策」を何か特別な処理のように思わせてるという状況が存在するので、そんな特別な言葉をお前ら使うなという主張は理解できる。

んで、高木氏はhtmlspecialchars抜けなどよくある例として指摘されているのですが。諸事横着でめんどくさがりなおいらは、「そんなのHTML_Template_Flexy使えば一発じゃーん」って考えてしまいます。これなら変数出力は基本エスケープ済みなので楽です。SQLは DB::prepare()を使いましょうｗ　これでクロスサイトスクリプティング脆弱性もSQLインジェクション脆弱性もばっちりカバーです。

もちろん、あらゆる原則には例外が存在するように、これらのPEARライブラリではどうにもならないケースというのもあるのですがね。

osCommerceの日本語日付表記がおかしい！

画面下の曜日を日本語表示にしたい

catalog/includes/languages/japanese.php 25行目の前に以下の3行を追加します。

//曜日の表示を日本語表記にする
$array_week = array("日","月","火","水","木","金","土");
$ja_week = $array_week[ date ("w")];

同じく catalog/includes/languages/japanese.php 31行目を

define('DATE_FORMAT_LONG', '%Y年%B%e日 %A'); // this is used for strftime()

から

define('DATE_FORMAT_LONG', '%Y年%m月%e日 ' . $ja_week . '曜日'); // this is used for strftime()

に変更します。

これで安心

osCommerceインストールメモ

register_globalsをOnにしないと動かないということはどういうことだ。

インストールディレクトリ以下に.htaccessで以下のように設定

php_value output_buffering Off 
php_value register_globals On 
php_value mbstring.language Japanese 
php_value mbstring.encoding_translation On 
php_value mbstring.http_input auto 
php_value mbstring.http_output EUC-JP 
php_value mbstring.internal_encoding EUC-JP 
php_value mbstring.detect_order auto 
php_value mbstring.substitute_character none; 

HTML_Template_Flexyまとめ

基本的な使い方
に簡単にまとめられているので参考になります。
outputObjectに突っ込むオブジェクトはStdClassを使っていたけど、FlexyController的なアドオンクラスを用意して、equalとか実装させないと辛いかなとか考えました。ただ、作るのも骨が折れるのでなんとか作業に支障の出ないように考えなければ。

高いレベルの意識を持ち開発を行おう

【PHPカンファレンス2006】PHPで書かれた実際のアプリケーションに潜む危険なコード

大垣氏はまず，「セキュリティのリスクはサブシステムとの境界の部分で発生する」と指摘した。サブシステムとは，データベース，メール・システム，ユーザーのWebブラウザといった外部のシステムのこと。「境界で入力時にきちんとバリデーション，出力時にきちんとエスケープ処理（フィルタリング）を行えば，かなりのセキュリティ・ホールは防げる」（大垣氏）。

以下セキュリティーホールとされているものを箇条書きに。
・未検証のユーザー入力値をそのままクエリーとして実行している。
・POSTのキーの要素名をクエリーに利用していた。
・POSTの値をそのままWebブラウザに返している部分もあった。
・セッションIDをブラウザで表示している部分は，古いPHPだと危険。
・またPHPのコードを埋め込むために「<?」（ショートタグという）を利用していたのも問題。ショートタグではなく「<?PHP」というタグを使うのが鉄則。
・ホーム・ディレクトリを設定する部分に，環境変数によって設定されるCGI変数である「HTTP_HOST」を利用している。
・「PHP_SELF」というサーバー変数を使っているのも問題。PHP_SELFにはPATH_INFOも含まれ，この部分に任意の文字列を入れることができる。
・タグを削除するstrip_tagsという関数の使い方も間違っていた。strip_tagsはタグは削除するがタグの中の属性は削除しない。このため，属性の部分にJavaScriptを埋め込むと実行できてしまう。
・str_replaceという関数で「’」と「￥」をエスケープしていた。データベースごとに専用のエスケープ関数が用意されているので，それを使うべき。
・Cookieの有効期限を365日に設定しているという問題もあった。こんなに長いのは論外。
・「.inc」という拡張子を使っているファイルがあるのも問題だという。サーバーの設定によってはPHPとして実行されない可能性があるからだ。
・addslashes関数によるエスケープを行っているという問題もあった。
自分は結構気をつけていると思うのだが、改めて心に刻み込もう。

IE6のデフォルト設定でクッキーを通してくれない件。

マイクロソフトぶっ殺す
PHP:IE6でサードパーティのクッキーを受け入れるようにする:P3P

PHPで言えば、setcookie関数でクッキーに値を設定する前に、

header("P3P: CP='UNI CUR OUR'");

という具合に、header関数でP3P情報を送信してやればいいのです。

むかついた。