Category perl.

自分が作るウェブアプリケーションでは基本的に以下のような規則を守るようにしている

  • GET だけで副作用 (DB書きこみなど) を伴う処理をしないこと
  • POST 時には自動的に CSRF 防止用トークンをチェックすること

これだけで単純な CSRF はまず防げくことができるからだ (実際は CSRF 防止用トークンの生成方法が多少問題になるが、作るウェブアプリケーションによって、どれほど厳密にすべきかが違うため、そのたび考えてやりかたを変えてる)

このような設計をした場合、全ての POST するフォームに input type="hidden" とかで CSRF 防止用トークンを埋めこむ必要がある。ウェブアプリケーションフレームワークによっては、防止用トークンを埋めこむところも自動的にやってしまうものもあるが、外部サーバへ POST するフォームなんかを作ったとき (ASP型の外部サービスとか)、意図せずトークンが漏れるのがちょっと不安なので自分は手動で全部入れることにしている。たとえ入れ忘れても、普通にチェックしていれば必ず気付くし、一行コピペするだけなのでこれで問題はまず起きない。

しかし一方、外部のアプリケーションから直接 POST されるような場合 (なんらかのコールバックとか)、当然ながら CSRF 防止用トークンは送られてこないため、自動チェックにはねられてしまう。なので、こういう場合は明示的に自動チェックをオフにする必要がでてくる。これが地味にややこしい。

Perl で Router::Simple などを使って適当に本体をディスパッチし、その前 (before_dispatch 的なもの) で自動チェックをかけるアプリケーションがあったとする (シンプルに作るとそうなるだろうというもの)。そんなときなんとなく以下のように書ければいいなと一瞬思ってしまうが、これはうまく行かない。

sub dispatch_foo {
    my ($class, $c) = @_;
    $c->check_csrf(0);
    # do something...
}

自動チェックはこのメソッドの前に実行されており、この段階、すなわち呼ばれたあとに「チェックしない」ことを宣言しても遅い。自動チェックをやめて、CSRF チェックするところにだけ $c->check_csrf(1) とか書いてチェックを明示的にするようにする、という解決方法もあるだろうけど、危ういので避けたい。

とにかく、自動的にチェックを行っている以上、そのチェックが行われる前に「この URI (やサブルーチン) に対しては CSRF チェックをしない」宣言をしておいて、自動チェック時にそのフラグを見る必要がある。理想としてはコードのコンパイル時に行われるのが望ましい。例えば以下のように

sub dispatch_foo {
    my ($class, $c) = @_;
    # do something...
}
__PACKAGE__->check_csrf(dispatch_foo => 0);

この場合、サブルーチンに対して CSRF チェックを自動チェックするかどうかを check_csrf() クラスメソッドで宣言しておくイメージになる。

これでとりあえずいいとは思うけれど __PACKAGE__ とか書きにくいし、dispatch_foo は2度出てくるしで、なんとかしくなる。

結論を言うと、この場合、以下のように CODE Attribute を使うのが一番スッキリいくように思った。

sub dispatch_foo : check_csrf(0) {
    my ($class, $c) = @_;
    # do something...
}

Catalyst 以来、最近は CODE Attribute を使っているものを殆ど見ておらず忘れていたのだけれど、こういうときはやはり便利だな、と思った。

これに従って、自分でウェブアプリケーションを作るときのスケルトンにも同じような仕組みを入れた。

  1. トップ
  2. tech
  3. CSRF 防止用トークンの自動チェックの問題と解決
  1. トップ
  2. perl
  3. CSRF 防止用トークンの自動チェックの問題と解決

  • ファイル処理には IO::File を使え。(IO::Handle, IO::Seekable)
  • LOCK_EX とかは use Fcntl;。でも IO::File::Lockable っていうモジュールがあったりする (使う?)
  • EOF まで一気に読み込む (ruby の File#read) には join "", $f->getlines とか、リストコンテキストで I/O 演算子使って join?
  • package; は deprecated. 戻すときは明示するらしい package main;
  • @ISA (あいえすえー、と読んでた) って何だよって思ってたけど、is_a だった。

クラスの作り方を寝ると忘れる。

  • 継承のやりかたを覚える。
  • use の挙動を把握する (use すると import ルーチン呼ぶんだぜって教えてもらった)
  1. トップ
  2. perl
  3. Perl 雑多メモ

コンテキストについて学んだよ。今回もとぴあさんくらむさんに親切に教えてもらったよ。

Perl ではコンテキストっていうのがあって、意識していないとハマるらしい (というかハマった)。サブルーチンを呼ぶところだけを見ても、そのサブルーチンが何を返すかがわからない。

$ perlsh
main[1]$ @arr = localtime;
56
21
1
18
4
106
4
137
0
main[2]$ $scr = localtime;
Thu May 18 01:22:02 2006

最初、なんでただの配列がスカラ変換のときに、タイムオブジェクト?のように見なされて時刻文字列になるんだ?って思ったんだけど、これは localtime がコンテキストによって挙動を変えた (!) 結果らしい。localtime っていう部分だけを見ても、localtime が何を返すかはわからない。


そのコンテキストとやらには、大きくわけてリストコンテキスト・スカラコンテキスト・void コンテキストがあるようだ。

sub context {
if (defined wantarray) { # void context では undef
if (wantarray) { # list context では true
print "List Context!\n";
} else {
print "Scalar Context!\n";
}
} else {
print "void Context!\n";
}
return;
}
@arr = context;
$scr = context;
context;
__END__
List Context!
Scalar Context!
void Context!

という感じで、サブルーチン内で wantarray を呼ぶことによりコンテキストの分岐ができる。wantarray っていう名前はおかしい (配列とリストは区別がある) みたいだけど、歴史的事情がきっとあるんだろう? perldoc でも wantlist であるべきだった的なことが書いてある。

たぶんコンテキストの理解は Perl では必須だろうけど、こういうのって他の言語だとあんまり見ないよね、っていう感じだった。


他今日知ったこと

  • use vars は obsolete。変わりに our
  • 擬似ハッシュには触るな (obsolete)
  1. トップ
  2. perl
  3. 今日のぺるる コンテキスト
  1. トップ
  2. prog
  3. 今日のぺるる コンテキスト