Perlは本当にオワコンなのか調べてみた

Perlは、日本国内では私と同年代(30代後半)の人を中心に、相変わらず人気があると思う。
しかし、私がよく見ているStackOverflow/DZone/InfoQ辺りでは、確かにこの数年はあまりPerlを見かけないという感覚があった。

そこで、Googleで『Perl site:stackoverflow.com』『1年以内の記事』のような感じで、いくつかのプログラミング言語の検索結果の件数を調べ、グラフ化してみた。




(;´Д`)…


ymgt先生のCookieMonster有りの場合のCSRF対策について

http://yamagata.int21h.jp/d/?date=20130302#p01

についてです。

実は、私も似た事を考えていました。
複数の同じ名前のCookieがあるという異常な状態を作り出すことによって、CookieMonsterがそこにいるかどうか調べることはできるのではないか、ということです。

でも、そのためには、掲示板へのPOSTのようなCSRF対象となるアクションの前に、ウェブアプリに一度アクセスしてもらい、Set-Cookieヘッダを食べてもらう必要があります。

しかしCSRFが仕掛けられた場合、必ずしもウェブアプリを事前に訪れてはくれずに、いきなり罠のページを踏んで一発リクエストがウェブアプリに飛んでくるわけです。
その時点でウェブアプリ側は、それがCSRFかどうか判定しなくてはなりません。

『Cookieが1つしかないから、Set-Cookieで複数のCookieを喰わせよう』
とする場合、CookieMonsterバグを持たないブラウザでは無限ループに入ってしまいます。

そのため、この方式の場合、User-Agentの値から、『そのブラウザがCookieMonsterバグを持つものか、持たないものか』を判別する必要があります。
持つものの場合には、Set-Cookieで複数のCookieを喰わせ、毒入りされていないことを確認できたらCSRFトークンをチェックして投稿を受け入れます。
持たないものの場合には、そもそも問題はないので、普通にCSRFトークンをチェックしてOKであれば投稿を受け入れます。

…で、IEだったら必ずCookieMonsterバグあるんですっけ?それなら上記でいけると思いますよヽ(´ー`)ノ


hsgw先生のXMLHttpRequestを使ったCSRF対策について

http://d.hatena.ne.jp/hasegawayosuke/20130302/p1

について

サーバ側でセッション管理せずに済むというメリットはでかくていいですね。
ログインの有無も関係なくなるのでカクイイです。
これからの時代はこういうのが主流になるべきという気がします。

デメリットですが
・JavaScript必須(hsgw先生が書いているとおり)
・画面遷移に影響が出る。普通のPOSTと違うので、アプリの挙動に影響がある
・古いブラウザでは動かない

という感じでしょうか。

追記:
var s =
encodeURIComponent( document.getElementById(“mail”).value ) + “&” +
encodeURIComponent( document.getElementById(“msg”).value );

みたいに自分でフォームのデータを生成する手間がそびえたつクソですね(;´Д`)
まぁ、ライブラリ化すればいいんでしょうが、そこに変なバグとか入ってきたりすると萎えるかも。

(追記)
値の名前(mailとか)が入っていないというバグが入っていたようです(;´Д`)ゴラァ
『古いブラウザ』って何?ってhsgw先生に怒られたんですが、もちろんNetscape Communicator 4系列とかです(;´Д`)