Selfkleptomaniac

au端末のみアクセス可能なサイトでクロスサイトリクエストフォージェリー対策が必要になったのだが、ワンタイムトークンとかのよくある手段だとおもしろくないので、何かないかと考えてみた。

auの端末からのリクエストには、端末の契約情報に紐づいた一意のID（サブスクライバID）がリクエストヘッダとして送信される。そこで、こんなのを作ってみた。

（１）リモートアドレスでauのデートウェイからのリクエスト以外は弾く
（２）POSTリクエストを受け付けるURIはサブスクライバIDで異なる

まあ（１）はよくあることなのでいいとして、（２）はこんな感じになっている。公開するURLは「http://example.com/form」とかいう形式になっている。au端末からそのURLへのリクエストがあると、サーバ側で「https://example.com/xxxxxxxxxx/」にリダイレクトする。この「xxxxxxxxxx」はサブスクライバIDとサーバ側に保持している特定のsaltとなる文字列（例えば創世記の全文）から生成されたハッシュ値になっている。リクエストしてきた端末のサブスクライバIDから生成したハッシュ値とURIのハッシュ値が一致すればリクエストを通して、そうでなければ弾く。リダイレクト処理が入るので「http://example.com/form」へのPOSTリクエストはリクエストボディーの内容が消えたGETのリクエストになってしまうから、もし第三者がこのURLに対してCSRFを仕掛けてきても無効化される。ハッシュ値付きの正しいURLにPOSTリクエストを投げるようにしたくても、端末が送信するサブスクライバIDとsalt値とハッシュ値の生成ルールが分からなければ犠牲者の端末専用のURLが推測できないため攻撃用のフォームを作ることができない。

あとは.htaccessなどで存在しないディレクトリへのアクセスをリライトしてしまえばおしまい。

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

とかいう感じ。いやっほう。

あんまり見たことないやり方なので破り方があるかどうかちゃんと検証できてない気がするけど、思いつかないので実戦投入した。

Popularity: 3% [?]

携帯サイト構築で忘れがちなセキュリティ対策を記録しておく。もちろん、外部に公開されているサーバで余計なポートが開放されていたり要らないサービスが起動していたりするのは論外。

SSL

SSLを利用している場合、基本的にSSLv3とTLS1以外を利用することはないので切っておく。特にNull暗号をオフにしておく必要がある。

Apacheだとこんな感じ。

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL

Poundだとこんな感じ。

ListenHTTPS
  Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL"

Apache

リクエストヘッダのHost部分を書き換えられることを前提とした設定をしていないケースが多いと思われる。VirtualHostの先頭にデフォルトの設定を入れて対応する。mod_rewriteは入っているものとみなす。

Apacheのバージョンが低い場合のTRACEメソッドの禁止も追加。

  DocumentRoot /var/www/html
  ServerName default.host.name
  RewriteEngine on
  RewriteCond %{REQUEST_URI} !^/server-status
  RewriteRule .* - [F]
  #TRACEメソッドの禁止
  RewriteCond %{REQUEST_METHOD} ^TRACE
  RewriteRule .* - [F]

Aliasで指定されたiconsやmanualは不要なので削除。

#Alias /icons/ "/var/www/icons/"
#
#
以下このディレクティブの最後まで。

PHP

基本的な設定はされているものとして、忘れがちなのをいくつか。php.iniの場合は

バージョン情報を晒さない。

expose_php = Off

リモートファイルをスクリプトとして読み込ませない。

allow_url_fopen = Off

リモートファイルをスクリプトとして読み込ませない。

display_errors = Off

続く、かも。

Popularity: 3% [?]

Hadoopでときどき「Incompatible namespaceIDs in /tmp/hadoop-user/dfs/data」みたいなエラーが出る。既知の問題らしく、namespaceのIDを記述したファイルを見ても同じだったりするので困るが、潔く

$ $HADOOP_HOME/bin/stop-all.sh
$ rm -rf /tmp/hadoop-user/* ←パスは設定ファイルに依存、間違えたら知らないよ
$ $HADOOP_HOME/bin/hadoop namenode -format
$ $HADOOP_HOME/bin/start-all.sh

で再フォーマットすると直る。

なかなか便利なトラブルシューティング集を見つけた。

Popularity: 3% [?]

この数日、サーバの負荷が急に増えたのでハードウェアを変更しました。これまでのマシンをプロキシにして、バックエンドにもう少しスペックの高いマシンを置いてコンテンツをそちらに移設しています。

新しいマシンはHPのProliant ML115 G5、AMD Phenom IIプロセッサにメモリ8GB、HDDに至っては合計2.5TB、さらにSSDが32GBという構成にESXiで3つのOSが動作しています。これまでのHPのデスクトップ用Celeronマシンとはかなり違いますが、こちらも安定して動いてくれることを願います。

猫大好きです。今日も二人で過ごしています。

Popularity: 2% [?]

ほぼ同じ内容のエントリを見つけたけど、よく忘れるのでここにメモしておく。

最近の傾向として、ウェブアプリケーションの導入前にセキュリティ審査が入ることが多くなったのだが、その際にApacheのバージョンが2.0.55より前の場合は

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)
    RewriteRule .* - [F]
</IfModule>

こんな感じでmod_rewriteを使ってTRACE（とかTRACKとかOPTIONS）メソッドを蹴るようにしないといけない。まあ、TRACKはIISでサポートされているけどApacheにはない（RFC2616のHTTP1.1の仕様にもない）のでいいんだけれども。

Apacheが2.0.55以降だと

TraceEnable Off

で済んでしまう。

Popularity: 50% [?]

「CouchDBによる次世代データストレージ」と題された文章があったので以下に訳出。著者はCouchDBの開発者。

原文はこちら。

『CouchDBによる次世代ストレージ』

コンピュータの世界は常に、速く、進化している。しかし、データを保存するやり方は数十年も（！）前に作り出されたものだ。現在のニーズに適応するために、古いシステムに対するワイルドなソリューションがなされてきた。このような実践はハッキングと呼ばれている。このようなソリューションは多くの人々にとって有用であるが、その一方で、根本的な欠陥が行き渡っている。つまり、それらはハッキングであり、システムの設計と実装の根本となるアイデアに背を向けているのだ。

CouchDBは現代のデータストレージに必要とされるものを満たすよう設計されている。サポートするべきレガシーは存在せず、ハッキングの必要なしに現在の、そして未来のシステムで動作することができる。もし「The four pillars of data management」にあるようにデータを保存、閲覧、安全化、共有する方法をお探しなら、CouchDBはその全てを備えている。つまり

保存…ローバストでACID対応のストレージエンジン

閲覧…データを効果的にフィルター、フォーマット、体系化するViewエンジン

共有…効率のいい、インクリメンタルで双方向的なレプリケーション

セキュリティ…分散セキュリティとバリデーションモデル

お手元のデータベースでは上のどれだけがサポートされているだろうか。

CouchDBはマルチコアCPUの複数台構成による分散処理を直接サポートしている。しかもデフォルトで。これからそれをご覧に入れよう。

いつ？

2007年6月12日、チューリッヒのWebtuesdayで。そのときお会いしましょう。

これだけ読んでもわかったようなわからないような感じなのでもうちょっと追いかけてみる。

Popularity: 4% [?]

LAMPに対抗して、MicrosoftがIIS上でPHPを動かす環境を宣伝している。MSSQLではなくMySQLやPostgreSQLを宣伝するというのも愉快ではあるが。

それより何より、やはり気になるのは

Linux + Apache + MySQL + Perl(PHP, Python…) = LAMP

に対抗したキャンペーンの略称が、

Windows + IIS + MySQL + PHP = WIMP

になってしまっていることだろうか。

英辞郎より：

wimp
【名】

弱虫、作話症｛さくわしょう｝、意気地なし、怖がり、勇気のないやつ、すぐあきらめるやつ
・You’re such a wimp. : 気が小さいね。
・That tequilla shot has been sitting there an hour, are you too much of a wimp to drink it?

さすが世界のMicrosoftはユーモアを忘れていない。

Popularity: 4% [?]

携帯端末の場合、サーバからステータスコード404が返ると、サーバ側のエラー画面を表示するのではなく処理を中断してしまうことがある（少なくともauではそうなった）ので、.htaccessでの制御で工夫しなければいけない。

普通、ステータスコード別に表示するHTMLドキュメントを指定する場合は

ErrorDocument 404 /error.html

のようにErrorDocumentディレクティブを利用する。しかし、ここで指定するのがローカルファイルへのパスの場合、ステータスコードはそのまま404を返してしまうため、携帯端末だとページを表示する前に処理が中断され、指定したドキュメントを表示させることができない。

解決方法は簡単で、

ErrorDocument 404 http://selfkleptomaniac.org/error.html

のようにリモートのURLを指定すると、この場合は404ではなくリダイレクトの302が返るため、携帯でも問題なく表示することができる。Apacheのマニュアルでは

リモート URL (例えば、頭に http と付与した方法) を ErrorDocument に指定するとき、 たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、 Apache はリダイレクトをクライアントに送出するということに、注意してください。 これにはいろいろと関連して起こる問題があります。 中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、 代わりにリダイレクトのステータスコードを受け取るということです。 これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとする ウェブロボットやその他クライアントを、混乱させるかもしれません。 さらに、ErrorDocument 401 にリモートの URL を指定すると、 クライアントは 401 というステータスコードを受け取らないため、 パスワードをユーザーに入力要求しなければならないことがわかりません。 従って、ErrorDocument 401 というディレクティブを使う場合は、 必ずローカルな文書を参照しなければなりません。

とのこと。

Popularity: 5% [?]

ブスコバンのアレルギーらしく、健康診断が終わってからずっとひどい頭痛だ。今日はちょっと家で休んでいる。

Yahoo JapanのAPI用に既存のPEARパッケージを拡張したServices_Yahoo_JPがある（作者サイト）。面白そうなのでさっそく使ってみた。

テキスト解析はこんな風に使える。例えばテキストの読みがなを取得する。

<?php
require_once 'Services/Yahoo/JP/MA.php';

$keyword = 'これは日本語です。';
$app_id = 'Your APP ID';

try{
        $yahoo = Services_Yahoo_JP_MA::factory('parse');
        $yahoo->withAppID($app_id);
        $yahoo->setSentence($keyword);
        $result = $yahoo->submit();

} catch(Services_Yahoo_Exception $e){
        $error = 'すいません、YahooJapanに接続できませんでした。';
}

if($result){
        $xml =& $result->xml->ma_result->word_list->word;
        foreach($xml as $key => $val){
            print($val->reading . "\n");
        }
}
?>

なるほど。で、何か面白いことでもできないかと考えたが、Yahooから戻ってくる読みがなをさらにローマ字に変換して、Mac OS Xに付属のsayコマンドで読み上げてみるのはどうだろう。

$ say -o 出力ファイル "読み上げるテキスト"

上の書式で変換できるので、フロントエンドのPHPと連携してみれば簡単だ。

そこでふと思いついた。sayコマンドは声の指定も可能なのだが、プリセットされたデータには歌いながらしゃべるパターンもあったはずだ。それを指定すれば、入力したテキストを歌うこともできるじゃないか。

$ say -o 出力ファイル -v "声のパターン名" "読み上げるテキスト"

そうと決まれば話は早い。というわけでデモを作成した。（Proof of conceptということで無茶なことはしないでくださいね）

テキストが入力されると、バックエンドのMacBookにHTTPで通信してプロシージャを呼び出し、MacBook側はテキストを元に音声ファイルを作成してMP3に変換、最終的に作られたファイルをDocmentRoot以下に設置してファイルのパスを返す。フロントエンドのウェブサーバにリバースプロキシでMacBookのローカルファイルにアクセス可能にしてあげていっちょあがり。文字で書くとややこしいが、図にするといたって単純。

追記：Yahoo JapanのAPI側で数字の読み方は返してくれないみたいだ。

Popularity: 5% [?]

Leopardにして困ったこと。

■Apache

　apachectlの「ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`”」の行でエラー。ulimitの引数が「unlimited」になるとエラーらしい。とりあえず動くし手元のテスト環境なので無視。

■pgpool-II

　起動したら「could not create shared memory segment: Cannot allocate memory」で死ぬ。どうにもわからんのでpgpoolに戻した。

■PHP

　PHP-5.2.5はiconv関連のエラーでビルドできない。ext/iconv/iconv.cを開いて:%s/iconv_open/libiconv_open/gと:%s/iconv_close/libiconv_close/gすればビルドできるようになる。Leopard対応できてない。

■kinput2-macim

　Leopard対応していない、と怒られてインストールできない。対策なし。

Popularity: 4% [?]