<?php

header("Location: http://www.example.com/");
exit;

?>

こんな感じでリクエストを普通にリダイレクトで飛ばすのが大半なわけだが、このリクエストがHEADで来た場合、リダイレクト先へのリクエストも当然ながらHEADになってしまう。

携帯サイトでOBJECTタグを使った場合、auなどはダウンロードページのOBJECTタグのURLに記述された先へHEADリクエストが飛ばされる（ことがある）。そこでOKが返らないとちゃんと動作しない。いつも飛ぶわけではなさそうなので、キャッシュの問題もあるのかもしれないが再現性があんまりなくて深追いしていない。

で、たとえばセッションで認証していたりする場合、$_SERVERのREQUEST_METHODを参照してHEADリクエストの場合は別処理にしてやるなどしないと、OBJECTタグでアクセスする先のファイルで認証エラーが発生したらログインページにリダイレクトで飛ばそうなんて処理を入れたら、HEADリクエストのままリダイレクトされてしまうので正常に動作しない。

しかし、それはそれでHEADリクエストを使って認証をかいくぐる方法なんかが考案されたらまずい。とはいえ、

$_SERVER['REQUEST_METHOD'] = 'GET';

とかやってももちろんLocationヘッダでリダイレクトしたらHEADリクエストのまま飛んでいってしまう。

というわけで、OBJECTタグでアクセスする先のファイルで認証を入れたい場合は、失敗したらいっそ404を返してファイルが存在しない、とかしてやった方がいい。少なくともHEADリクエストのままどこかに飛んでいってページが正常に表示されなくなるよりはまし。

なんか北米版だと選手データを編集できるのに日本語版だと出来ないとか、日本語版の方が高いとか文句いわれているようだが、選手の編集なんかしたくないし、北米版が日本語音声になるのか知らないからどうでもいい。

個人的には、不当に評価の低かったダスティン・ペドロイアやカリル・グリーンがちゃんと是正されているか、特定の変化球（特にカーブ）が異様に効果が高くてバランスを崩さないかが気になる。それと、40人ロースターにちゃんと対応しているか。正直、育成には興味がない。

しかし、注意しなければいけない。VmHWMはたとえばCentOS 4.5でカーネルを更新していなかったりする場合は表示されない。

では、いつそんなものが表示されるようになったのか。さすがにそんなマニアックなことはちょっとわからなかったので調べてみた。Googleではなかなかヒットしてくれない。仕方がないのでkernel.orgから2.6.xxのChangelogだけwgetしてgrepで探してみたら、2.6.15に

And there has been no collector of these hiwater statistics in the tree. The
new convention needs an example, so match Frank’s usage by adding a VmPeak
line above VmSize to /proc/ /status, and also a VmHWM line above VmRSS
(High-Water-Mark or High-Water-Memory).

という記述を発見。こいつだ。

太郎「どうもー、リーマン太郎です！」
次郎「どうもー、リーマン次郎です！」
二人「リーマン・ブラザーズで～す！」

音：ガラガラガラ、金融ショック！

父「やあ、わたしが父さんだよ」
太郎、次郎「わぁい、リーマン・ブラザーズ倒産だ！」

息子の反応：なし。

次のお話。昔々、あるところにお腹をすかせたかわいそうな兄弟がいました。兄弟は悪い人たちにさんざんいじめられて、冷たい雪の降る寒い冬だというのに、隙間風の吹き込む暗い部屋で、薄い布団一枚に身を寄せ合ってガタガタ震えています。

お兄さんは弟をはげまそうとして言いました。おいしい食べ物のことを考えよう。きっと体があったかくなるよ。弟は言いました。おいら、腹いっぱい天丼が食べたいなあ。えび天、いも天、なんでもいいよ。ああ、天丼ってうまいんだろうなあ。

すると、薄い壁を蹴破って、大きな筆を抱えた弘法大師があらわれました。

「やあ兄弟、腹へってんだってな。なんか空海？違うか」

あっけにとられる兄弟を尻目に、弘法大師は懐から墨汁のパックを取り出すと、大きな筆の先にじょぼじょぼ振りかけて、さっと構えます。

「わがなしそめし技を、よおく見ろ！」

弘法大師は筆をぐわりと一閃させると、兄弟の部屋の天井の真ん中に、大きな点をひとつ描き入れて叫びました。

「天丼！」

もう雪が吹き込むのを防いでくれる壁はありません。兄弟は、しんしんと降りしきる雪の音を聞きながら、やがてゆっくりと、暖かい眠りに就きましたとさ。おしまい。

反応：長男は天井っていう字を知らない。

そうでもない頃。

なぜ聴かない？

投手戦の素晴らしさは、それがプロフェッショナルとしての選手やベンチの力量を際立たせ、厳しい展開の中でようやく飛び出すヒットの価値を否応無しに高めるところ、また一瞬の隙が生むミスに勝負の厳しさを思い知らされるなど、個々のプレーの質的問題の重要性が増す様に興奮させられる点にこそある。１０本も２０本もヒットが出る試合はその価値も急激なインフレーションを起こして魅力が褪せてしまう。

さて、ゲームの方は、中継ぎ投手の登板過多という問題を抱えたチームとして、今日のヤクルトの攻撃は素晴らしかった。相手にも同じ目に遭わせてやろうとチーム一丸となっていたからだ。バーンサイドが３回１アウト時点で７０球を費やし、５回までで降板せざるを得ない状況を作り出したのは見事としかいいようがない。その一方で、中継ぎ投手の出し惜しみから先発投手を引っ張りすぎて８失点したのは悲劇を通り越して喜劇となってしまったが。

６回まで、両チームともヒット数と得点が同じか、またはヒット数から１を引いた数が得点というのは変わらず、奇妙な均衡を保ったままゲームは進んだ。その均衡が破れたのは、次のイニングが９番バッターからということで中継ぎピッチャーの交替が後手に回って、読売が５点差を追いつかれたときで、ヤクルトは以降得点よりヒット数が１多いまま試合が終わってしまった。残念。

試合の決着がついたのは８回。ひさしぶりに見る五十嵐は、そこそこの球を投げているようには見えたが、やはり全盛期ほどではない。これまで新聞で成績をみる限りでは、三振は奪うがホームランも打たれるようで、いまいち復活したのかどうかわからなかったが、今日ではっきりとわかった。阿部のホームランで１点差。去年神宮でもらった背番号５３のヤクルトのユニフォームを着ている自分を幽体離脱してしばし眺める。

９回、クルーンは投球練習から１５４キロを計測。以前日本ハムの試合を観たときより調子はよさそうだった。が、ファーボールの連続でノーアウト満塁に。１点差でこの展開、しびれる。ここで阿部がクルーンのボールを捕球したまま返球しないという荒技を繰り出した。マウンドとホームベースの間あたりで話し込む阿部、クルーン、あとついでに近寄ってきた小笠原。何を話していたのかはわからないが、ヒーローインタビューの阿部はかなり態度が悪かったので、たぶんあまりのクルーンの情けなさにブチ切れたのだろう。ある意味でいいものをみた。

手順は以下の通り。まずデータベース、テーブルを作成します。

mysql> create database sec_test;
Query OK, 1 row affected (0.02 sec)

mysql> use sec_test
Database changed
mysql> create table test (username char(16));
Query OK, 0 rows affected (0.01 sec)

ご覧の通り、char(16)でusernameというカラムを持つテーブルを作成します。

まず「admin」というusernameを持つ行を作ります。

mysql> insert into test (username) values ('admin');
Query OK, 1 row affected (0.00 sec)

mysql> select count(*) from test where username = 'admin';
+----------+
| count(*) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

出来ています。

次に、問い合わせの文字列部分の後ろに空白を追加してみます。全部で16文字になるようにしました。

mysql> select count(*) from test where username = 'admin           ';
+----------+
| count(*) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

後ろの空白が無視されているのがわかります。update:正確にいえば、char型なので指定された長さ未満の文字列は空白文字で埋められるみたいです。null文字とかじゃないんですね。

次に、char(16)の範囲を超えたところで「x」を追加して検索してみます。

mysql> select count(*) from test where username = 'admin           x';
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

さすがにヒットしませんでしたが、そもそもカラムの制限長を超えているのにエラーにはなりません。

では、この値をINSERTしてみます。

mysql> insert into test (username) values ('admin           x');
Query OK, 1 row affected, 1 warning (0.01 sec)

mysql> select count(*) from test where username = 'admin';
+----------+
| count(*) |
+----------+
|        2 |
+----------+
1 row in set (0.01 sec)

「admin」としてINSERT出来てしまいました。

これで、（１）既存のデータに重複行があるかチェック（２）なければINSERT、という処理で重複登録を防ごうとしてもダメなことがわかります。

ちなみにPostgreSQL 7.4.19でテストすると

db_test=# create table security_test (username char(16));
CREATE TABLE
db_test=# INSERT INTO security_test (username) VALUES ('admin');
INSERT 0 1
db_test=# SELECT COUNT(*) FROM security_test WHERE username = 'admin';
 count
-------
     1
(1 row)

db_test=# SELECT COUNT(*) FROM security_test WHERE username = 'admin           ';
 count
-------
     1
(1 row)

db_test=# SELECT COUNT(*) FROM security_test WHERE username = 'admin           x';
 count
-------
     0
(1 row)

db_test=# SELECT COUNT(*) FROM security_test WHERE username = 'admin            ';
 count
-------
     1
(1 row)

db_test=# INSERT INTO security_test (username) VALUES ('admin           x');
ERROR:  value too long for type character(16)
db_test=# SELECT COUNT(*) FROM security_test WHERE username = 'admin';
 count
-------
     1
(1 row)

db_test=#

INSERTはできません。8.3.3でも。

db_test=# create table test (username char(16));
CREATE TABLE
db_test=# INSERT INTO test (username) VALUES ('admin');
INSERT 0 1
db_test=# SELECT count(*) FROM test WHERE username = 'admin';
 count
-------
     1
(1 row)

db_test=# SELECT count(*) FROM test WHERE username = 'admin           ';
 count
-------
     1
(1 row)

db_test=# SELECT count(*) FROM test WHERE username = 'admin           x';
 count
-------
     0
(1 row)

db_test=# SELECT count(*) FROM test WHERE username = 'admin            ';
 count
-------
     1
(1 row)

db_test=# INSERT INTO test (username) VALUES ('admin           x');
ERROR:  value too long for type character(16)

INSERT時にあふれた分が勝手にカットされることはありませんでした。

１　推測されやすい乱数生成の問題

PHPのrand関数はlibcのrandのラッパで、mt_randはメルセンヌ・ツイスタ擬似乱数生成装置の実装なのだが、どちらも32ビット型符号なし整数をシードにしている。しかし、実装の問題により実際にはそれ以下の強度にしかならないそうだ。そのため、暗号化に際してこれらの関数を利用するのは不適切ということになる。それに対処したようだ。

２　MySQLのクエリの長さ制限の問題

MySQLではデフォルトでサーバとクライアント間で送信されるクエリとその応答の長さがmax_packet_sizeディレクティブ（っていうのかな？それはApacheだけ？）で1MBに制限されている。もし1MBを超えたクエリがクライアントから送信された場合、MySQLサーバ側でエラーとして処理してしまう。

たとえば、期限の切れたセッションデータをDBから削除するようなクエリがあり、意図的にこのクエリが長くなるようなデータをセッションに埋め込むことができれば、クエリはいつまでも実行されず、何かしら問題が起きることになる。

update: もっとすごい問題があった。

３　MySQLのダメダメな文字列比較ルール

MySQLにこんなクエリを投げる。

SELECT * FROM user WHERE username = 'admin';

たとえば、ユーザ登録の際に登録名の重複チェックをしているとしよう。WordPressのように、そのサイトにはadminという名のユーザが必ず存在するとして考える。新規のユーザが登録時に「admin」という名前を使おうとすると、上のようなクエリでチェックが行われ、すでに登録されている名前であるとしてアプリケーションによって登録がはじかれる。まあ、そういう仕組みのウェブアプリがあるものと思ってもらいたい。

このusernameというカラムが、たとえばchar(16)だったとする。MySQLではSELECTによる比較時にクエリ内の文字列の後ろの空白は無視されるようになっている。「admin           」だと、

SELECT * FROM user WHERE username = 'admin           ';

こうなるが、実際には最初のクエリと同じ扱いになる。

ところで、じゃあ「admin           x」という名前を使おうとしたらどうなるだろう。ここでは意図的に名前をchar(16)から外れるようにした。数えにくいかもしれないが、17文字ある。

SELECT * FROM user WHERE username = 'admin           x';

MySQLでは、比較の際にはカラムの型を無視してくれるので、上のSQLは何も返ってこない。つまり、新規登録可能なユーザ名として認識される。そこで、INSERET処理を実行すると、今度はカラムの型をみて余分なところはカットし、さらに後ろの空白を取り除くので、あれま、「admin」という名前でユーザ登録が完了してしまう。

これでadminアカウントの乗っ取りが完了する。ひええ。

もちろん、UNIQUE INDEXで対処することは可能だが、そうでないアプリケーションなら困ったことになる。

未検証なのでなんともいえないが、本当だったらこわい。

update:再現しますた。

男脳とか女脳とかいわれると反発を覚えるのは、当然のことだ。というのも、なんとか脳というのが、あるときは環境により決定される、またあるときは遺伝により決定される器質的問題であるかのように語られるのは、ちょっと考えればどちらも正しいとはいえないのに、まるで何かの決定論みたいに語られるとむかつくのは当然だからだ。

環境により決定される、というのは、たとえばゲーム脳とかがそうだが、周囲の環境によって脳がある決まったパターンの働きをするようになってしまうというもの。暴力的なゲームをやりすぎることにより、脳が現実とゲームの違いをきちんと認識できなくなって現実社会で暴力を起こすようになるのだ、とかなんとか。

もちろん、人間の行動は環境に影響される。しかし、相関関係と因果関係を綿密に調べるなら、それが脳の器質的問題となることはめったにない。そもそも、脳はそんなに単純なものではなく、また一見単純に思われる人間の行動も、その動機や背景となる理由には様々な要素が絡み合っている。

ゲーム脳の明らかな間違いには、この説を唱える学者自身の偏見がそのまま反映されているのが興味深い。ある人間の行動が環境により影響されるという、これ自体はごく当たり前の考え方と偏見とが科学の名前で結びつくと、単なる偏向以上の強い影響力をもった学説として立ち現れるのは、たとえば「人間の測りまちがい」を読んだ人にはなじみ深いものだろう。

遺伝的な決定論として男脳や女脳を唱える人は、古典的優生学の生き残りの差別主義者であるのはもちろんだが、たとえば貧困が絶望を生むとか女性の置かれた社会的なプレッシャーが女性の行動を限定しがちであるとか、そういった社会的要因を全て逆転させてしまって、女がこれこれなのは生まれつき脳がこれこれだからだ、という決定論に胡坐をかいて何も見ようとしない愚か者でしかない。

しかし、経験的に女性がこうでありがちだ、という特徴が全く存在しないわけではない。たとえば、上のリンクの日記に書かれたようなことが、実際に統計をとったら事実として認められることもあるかもしれない。解決方法を提示されるより共感されることを好む女性の方が多いという結果を生む調査だってやればできる可能性はある。

しかし、ここまで述べたように、それが遺伝的な器質的問題であったり、単純な環境の問題であると決定したりするのは同じレベルの誤りである。相関関係と因果関係はよく取り違えられる仲の悪い双子のようなもので、ある傾向（女性は共感されるのが好き）をとらえることができれば、たちまちのうちに因果関係（女性の社会的地位による、女性の脳の器質による、などなど）を説明できてしまうと考えるのは愚かな行為以外の何物でもない。

でも、ある意味ではそれも健康な反応であるともいえなくはない。だって、女性の行動についてその原因を探ろうと思ったら、簡単に見えたとしても実際にはとても難しく、問題をとらえる視点によって結論も左右されてしまうような、決定的な手段もいまだ提供されていない未開拓の分野なので、ひどい泥沼にはまることになるだろう。生兵法は怪我のもと。他にやらなければいけないことがたくさんある人なら、ひょっとしたら「ああ、まあそれが女ってもんだよ」と片付けてしまいたくなるのも当然だからだ。

なので、男脳とか女脳とかいうのは、知りたくても知ることができないものについて、手が届きそうで届かないまま、どうにかおのれを納得させうようとする人々の哀れな最後っ屁ととらえるのが最も慈悲深いやり方なのだろう。もちろん、それが実害をもたらすレベル、たとえばあなたの前にいる人が本気で男脳とか女脳とか言い出してあなたを責める、貶める、蔑むような状況でない限り、ほっときゃいい。そういう状況なら、存分に罵倒すればいい。ネタならいくらでもある。

自分自身についていえば、こういう「女とは」みたいな話をするときは、かみさんが何かしたりしてイライラしたときだけで、それを読んでかみさんが激怒したらちょっとだけすかっとするから、という不純な動機による言明でしかなく、科学的な厳密さについては全く考慮していない。夫婦円満を目指す手段のひとつにすぎない。

納得できない人は、アパッチ加山もやってみたBBCのSEXテストをどうぞ。階級差は知能の差であり、階級の低い人間は教育しても決して理解はできないという強い偏見に長いこと苛まれてきたイギリスの考える性差についていろいろ面白いことがわかるかもしれない。

というわけで、とうとうtaspoに申し込んだ。あんなのすぐなくなるに決まってる、自販機の中のFOMAカードをテロリストに盗まれてデータ通信し放題にされるに違いない、という楽観的な予想は中毒症状の前にあえなく敗れ去ったのだ。

さっそく申込用紙を記入した。よく宛先の「行」を二重線で消して「御中」に直す人がいるが、効率を大事にする現代人なら

こうやっておくのが正しい。

＊これの元ネタはどこかのサイトにあったはずなのだが思い出せない。誰か教えて。