 Hideki Sakamoto |
|
雑記
2005-07-03 [長年日記]
◆ F1ヨーロッパのどこかフランスGP
アロンソ楽勝するも、キミの不気味な影。とはいえマクラーレンは信頼性がいまいちですが。シュー兄は作戦でやっとこ3位。実は去年もそんなにマシンの差はなかったんじゃないかと思えるほど見事な戦略勝ちでした。琢磨は1回目のピットストップを「普通に」こなしたため、トゥルーリの前に出られず無理した結果オーバーラン。さらに走っていた位置が悪く、他人のアクシデントに巻き込まれてコースオフ。結果論で言えば、シュー兄と同じ作戦をB.A.R.が出来ていたら、表彰台にあがれてたかも。トヨタ、ウィリアムズはなんだったんでしょう？トゥルーリは完全にペースメーカー状態、他の3人は映りもせず。とか言いつつトヨタは2台ともポイントフィニッシュですか。ミナルディの2台は私には両方ともタイヤバーストのように見えましたが、ブリジストン大丈夫？？表彰台には教授が。あ、フランスGPだ。タイトル修正。
◆ <%= isbn 4798102792, 'アンドキュメンテッドMicrosoftネットワーク' %>(翔泳社)
3年前の本なんですが、読んでよかった。「4798108545(翔泳社)」の前提知識の予習のつもりが、長年の疑問がこれだけで解けちゃいました。\\server\folder ではアクセスできるのにマイネットワークに現れない理由を知りたいとか、sambaサーバのファイル共有にNAT越しでアクセスするためのフィルタのやり方とかを理由を含めて知りたい人にはぜひお勧めです。
2005-07-07 [長年日記]
◆ 備忘
VC6での
uuid.lib(unknwn_i.obj) : fatal error LNK1103: デバッグ情報が壊れています; モジュールを再コンパイルしてください
link.exe の実行エラー
というエラーは、VC6とPlathome SDKの互換性の問題。Plathome SDK内(C:\Program Files\Microsoft Platform SDK\Lib)のUuid.Libの名前を変更して使わないようにすることで回避。ってライブラリの整合性とかセキュリティホールとかは大丈夫なんだろうか。
2005-07-15 [長年日記]
◆ エアコン
会社の新事務所のエアコンが入居当時から調子が悪く、座っているだけで汗が出るような状態ではや一月半。入居してすぐに管理事務局に修理依頼をしていたのに、なかなか修理にこないので再依頼。いつの間にか「メーカに修理依頼する」が「しばらく様子を見る」にすり替わっていた。なんじゃそりゃ。
で、様子を見に来た事務員さんが惨状を目の当たりにして強くプッシュしてくれたおかげで、すぐにメーカの修理担当者が来てくれることに。途中一時的に冷風が出てきたりして、原因をなかなか突き止められなかったが結局はガス漏れとのこと。とりあえずガスを補充して連休をしのぎ、本格的な修理は連休明けということで決着。
修理の兄ちゃんが使っていた温度計がかっこ良かった。
◆ 本格始動
というわけで、事務所がだいぶすごしやすくなったので、椅子の微調整。実は今日まで『高いくせに普通』という評価だったのが一変。ここ数週間つらかった腰痛の痛みが、この椅子に座ってコンピュータに向かうと治まる。すばらしい。
私の机は今こんな感じです。こうして客観的にみるとかなり贅沢だな。
2005-07-16 [長年日記]
◆ 液晶テレビ
仕事をしつつ後ろで会社にある国産のテレビ機能付き液晶ディスプレイを流してるんですが、いやこりゃひどい。ちょっとまじめに調整しても肌色系の色が出ないとか、そもそも色ノイズ出まくりなのは、電波状況のせいもあるかもしれないので、かなり気になるもののまあ我慢することに。とにかく我慢できないのは応答速度の悪さ。メーカのサイトを見に行くと、一応最近機種で、「応答速度8msを達成」とか自慢げに書いてあるのに、そんなに早くないパン・ズームやカメラの前を端から端まで１秒ぐらいの早さで人が歩いて横切っただけで画像が激しくブレる。野球中継ではピッチャーの手の振りがみえない。バレーはボールが魔球よろしくワープする。とスポーツ中継はずっと見続けてると誇張でなく頭がくらくらしてきて、見れたもんじゃありません。中継ものは最近コマ数を落としていることがあるのでそのせいじゃないか、と思われるかもしれませんが、同じアングルでのスロー再生だとちゃんと映ります。さらにスタジオ収録ものやドラマでも、出演者が頷いたり手を振ったりすると残像出まくりですわ忍者かと(嘘です)。あ、今麦畑の映ったコマーシャルが流れたんですが、後ろは潰れてしまって単なる砂漠、手前で風に揺れてる穂はブレまくり。こういう画像もだめと。
見続けてれば慣れてしまうのかもしれませんが、それって視覚の退化を意味するような気がして、絶対に慣れたくないなあ。こういう映像だけ見て育った子供って動体視力とかおかしくなるんじゃないかと心配になるぐらいです。ちなみに私は都内の快速電車で山田太郎のまねを試みて正解率0%だったので、動体視力が良いという訳ではありません。
次はいわゆる薄型テレビかなと思ってたんですが、当分はやめとこう。すでに持っている人にはちょっとショッキングな内容かもしれませんが、私が指摘した要素を手元のテレビで注意して見て頂いて、評価の参考にして頂ければと思います。怒らないでね。
あ、天気予報の映像はきれいだな。
◆ MacOS修行中(1)
「^↑J」でかなり悩む。マニュアルにも書いてないし、検索しても出てこない。ショートカットキーを使いたがる超初心者というのは、誰も想定していないらしい。
◆ MacOS修行中(2)
すぐ「Alt+`」を押す。キーバインドを変えるべきか、頭に「ことえりモード」を植え付けるべきかちょっと迷うが、とりあえず後者の方向で。
◆ MacOS修行中(3)
1時間ほど、リモートマシン上でのjlessとjvimを使うたびにいちいちターミナルの文字コードセットを切り替えて使っていた後、setenv JLESSCHARSET japanese-eucすれば良いことに気づく。kterm とか TeraTerm とか Poderosa だとISO 2022-JP が混ざってても良かったんだよぅ。
2005-07-17 最近のSSL事情について [長年日記]
◆ [SSL] 最近のSSL事情について
先日、WASフォーラムの第2回コンファレンス に行ってきたんですが、午後のセッションで講師の高木 浩光さんがphishing対策の文脈でSSL通信時に利用者にできる自衛策として、
- URLの目視確認
- 錠前アイコンの確認
- SSL証明書に関する以上警告には常に「いいえ」を選択する
の3点の徹底を挙げていました。2番目は常識、3番目はちょっとでもセキュリティに気をつけている人なら必ず実践していると思いますが、最初のURL確認はどうでしょう? なぜそうする必要があるのかといったあたりを起点に、現在のSSL事情に関して私なりにまとめてみました。眉に唾してお読みください。
題材としてはいま流行のphishing詐欺を扱います。ただし、特殊な書式のURLとか、IEのセキュリティホールを付くとかいった高度な手口ではなく、似非URLを使って利用者をだますという非常に古典的な方法です。前述した3項目のうち、2、3番目のチェックをパスするためには、ブラウザに標準でルート証明書がインストールされている認証機関からSSL証明書を取得する必要があります。この前提を崩さずに、似非ドメインのサーバ用SSL証明書を取得することができるか、という所を出発点として考えます。
◆ 匿名で警告の出ないSSL証明書は取れるか？
実はSSL MITMのエントリ(2003/12)を書いた時期に、上記のような疑問を持って少し思考実験と調査をしたことがありました。当時は『不可能ではなさそうだけど、ちょっと足が付きやすいかな』といった結論だったのですが、その後の情勢変化により、今現在は『さほど(犯罪者視点で)リスクを犯さずに入手可能』と思っています。以下はやや不穏な内容になってしまいますが、「今そこにある危機」を実感できる程度のバランスになるように注意したつもりです。
証明書を取る前に、まずドメインを取得する必要がありますが、これはご存知の通り、gTLDや汎用JPドメインなら誰でも取得できます。詐欺を実行しようとする場合、出鱈目な名義と住所で取ってしまうでしょう。ドメイン取得時の支払いも、昨今のニュース等を見ていると何とかなりそうです。
ドメインを取得したら、さっそく証明書、ではなくまずサーバを調達します。以前の思考実験ではここで頓挫したのですが、去る2月に、個人的にはかなり衝撃的な注意喚起が発表されました。つまり、クラックしたサーバで勝手にサービスを立ち上げてしまえばよいのです。この手口を使えば身元を隠してサーバを立ち上げることができてしまいます。
これでサーバも準備できましたので、このサーバでDNSとメールサービスを立ち上げます。セカンダリはなんとでもなるでしょう。
さて、いよいよ証明書の入手ですが、これには先ほどのサーバを利用します。私が調べたごく限られた範囲でも、特定のメールアドレスにメールが届くだけで、サーバ用証明書を発行してくれる業者がいくつか見つかりました。つまり、クラックしたサーバと匿名で入手したドメインを利用すれば、匿名で警告のまったく出ないSSLサーバ証明書を入手することができてしまいます。
これで最初に挙げた3項目のうち、2番目と3番目の項目をすり抜けるための準備はできました。しかし、この方法では、すでに他の人によって取得済みのドメインに関して、SSL証明書を取得することはできません。じゃあ問題にならないかというと、そうでもありません。
◆ 匿名で入手したSSL証明書を使って何ができるか
例えば、on-sky.netドメインでオンラインショップを運用していたとします。このサイトがある日、フィッシング詐欺を働こうとしている人間のターゲットとなりました。さてどうするか。そいつは、「0n-sky.net(最初の文字が数字の0)」というドメインとSSL証明書を取得し、SSL MITMを仕掛けます。
どこかで見たような図ですね。被害者のクライアントと犯罪者の中継器の間では「0n-sky.net」ドメインのSSL証明書を使って通信が行われます。もちろんSSLに関する警告は出ません。それをいったん平文に直し、個人情報等を盗み取った後、正しい「on-sky.net」ドメインに中継します。被害者の買い物は何事も無く完了しますので、情報を盗み取られたことになかなか気づけません。
[コラム]URLチェックの限界
この例はまた、URLの目視確認の難しさも示しています。日本語ドメインになると、同形異字や類形異字もありますので、さらにややこしくなります。アルファベットにしても、ローマ字読みの「L」と「R」とか、「.co.jp」に対して「.com」他を取るとか、応用はいくらでもあります。私も含めたエンドユーザーは、そうした可能性も含めて「正しいドメイン名」をちゃんと知っておかないといけないのですが、メジャーな相手や、実際の店舗を訪れることができるような所でないとなかなか難しいでしょう。
実はこの問題、私の記憶違いでなければ、SSLの黎明期に一度通った道です。当時はSSLのメリットのひとつとして『第3者機関が審査した上で、身元のはっきりした相手にのみ証明書を発行するので、わざわざURLのチェックをする必要がなくなる』というようなことが言われていました。今でも字面の上ではそれは正しい主張です。ただし、その審査基準に、以下で述べる「メールが到達可能であれば、実在確認の必要は無い」というものが存在することを忘れてはなりません。
◆ 混同されている異なる種類のSSL証明書
どうしてこんな問題が起きるのかというと、「何も保証しない」SSL証明書、「実在証明付き」SSL証明書などといった、複数の種類のSSL証明書があるということがそもそもあまり知られていない。さらには、利用者はもちろんのこと、一部の証明書発行機関にさえも、それらの違いが存在する訳があまり理解されていない。といったあたりがその理由ではないか、と考えています。まずはSSL証明書の種類について簡単におさらいします。
いわゆる無保証のSSL証明書というのは、最近ぽっと出てきたというわけではなく、IPAの各国電子政府および PKI プロジェクトの調査報告書によると、1998年のカナダやアメリカの政府の証明書ポリシーには既にそうしたレベルの証明書に関する記述があるようです 。例えば、アメリカ政府では証明書のレベルを原始（Rudimentary）、基礎（Basic）、中間（Medium）、高度（High）、テスト(Test)の5つに分けています。上記報告書よりそれぞれのレベルの認証の範囲に関する説明を引用します。
- （１）原始レベル
- 個人に対する最も低い保証レベルで、署名された情報に対してデータの完全性を提供すること、主要な機能である。 このレベルは悪意に対するリスクが低い環境を想定しているため、認証を必要とするような取り引きには適しておらず、また、機密性が要求される取引に対しても不十分なものである。なお、より高いレベルの証明書が利用できない場合は、機密性が要求される取り引きで利用してもよい。
- （２）基礎レベル
- このレベルは、リスクがあり、その結果としてデータが危殆化する可能性はあるが、そのことがそれほど重要であるとみなされていない環境、すなわち、悪意を持って個人情報へアクセスする可能性が高くないような状況を想定したものである。
- （３）中間レベル
- このレベルは、リスクがあり、その結果としてデータが危殆化する可能性が中程度である環境、すなわち、金銭的な取り引きで詐欺に遭う可能性があるものや、悪意がある個人情報へのアクセスの可能性が存在するような環境を想定している。
- （４）高度レベル
- このレベルは、データに対する脅威が高く、セキュリティ関連サービスが機能しない可能性が高い状況、すなわち、高額な取り引きや、詐欺に遭う危険性が高い環境を想定している。
- （５）テストレベル
- FBCA(Federal Bridge Certificate Authority:連邦ブリッジCA)とPCA（Principal Certificate Authority:筆頭CA)の間で実施される互換性テストのためのものであり、この目的のためだけに試用される。
実際に発行されているSSL証明書が、この定義のどれかに直接当てはまるというわけではないのですが、証明書の種類と、その適用範囲についての理解の助けにはなると思います。
では、実際の民間認証局はどういったポリシーを利用しているのかというと、どうもベリサインのCPSにある「クラス」という概念に準拠した基準を採用しているところが多いようです(ベリサインが本当に大元なのかどうかは自信なし)。認証機関のページを回っていた時に、「クラス3の認証」といった言葉をあちこちで見かけたのですが、どうもこれはベリサイン社のCPSで定義されているクラスを指しているようです。このCPSより、各クラスの概要についての記述を引用します。
クラス1証明書は、日本ベリサインのサブドメインにおける最も低いレベルの保証を提供する。クラス1証明書は、個人向けの証明書で、その検証手続きは認証機関のサブドメイン内で利用者の識別名が一意かつ明確であること、並びにある電子メールアドレスがある公開鍵と関係するという保証に基づくものである。クラス1証明書は、同一性の証明が必要とされない非商業取引または少額取引におけるデジタル署名、暗号化およびアクセス・コントロールに適当である。
クラス2証明書は、他の2つの証明書の中間のレベルの保証を提供する。クラス2証明書も個人向けの証明書である。クラス1証明書の検証手続きに加え、クラス2証明書の検証手続きには、証明書申請者の提出した情報を、取引上の記録もしくはデータベースの情報または日本ベリサインの承認した同一性を証明するためのデータベースの情報と比較する手続きが付加される。クラス2証明書は、同一性の証明を必要とする中間価額の取引におけるデジタル署名、暗号化およびアクセス・コントロールに利用することができる。
クラス3証明書は、日本ベリサイン・サブドメイン内で最高のレベルの保証を提供する。クラス3証明書は、個人、組織並びに、認証機関および登録機関の管理者に発行される。クラス3証明書は、同一性の証明を必要とする高額取引におけるデジタル署名、暗号化およびアクセス・コントロールに利用することができる。クラス3個人向け証明書は、利用者の本人出頭に基づき利用者の同一性を保証する。同一性確認は、最低限、広く認識された様式の政府の発行した身分証明書ともう一通の身分証明書を利用して、利用者の同一性を確認する者の面前でなされるものとする。個人向け以外のクラス3組織向け証明書は、認証、メッセージ、ソフトウェアおよびコンテンツの完全性の維持、機密保持のための暗号化を行うために、各種デバイスに発行される。クラス3組織向け証明書は、利用者である組織が実際に存在すること、当該組織が証明書申請を承認していることおよび当該組織を代理して証明書の申請を行う者がその権限を有していることを確認した上で、利用者の同一性についての保証を提供する。サーバ用クラス3組織向け証明書（セキュア・サーバIDおよびグローバル・サーバID）は、利用者が証明書申請に記入されたドメイン・ネームを利用する権利があることも保証する。
クラス1と2は「個人用」と明記されています。さらにクラス1について詳しく見ていくと、「認証機関のサブドメイン内で利用者の識別名が一意かつ明確であること」というのは、ベリサインとその子(親)会社の範囲内で、同名の利用者に対して既に証明書が発行されていないこと、という意味だと思われます。これは当然ですね。で、もうひとつの要件が「ある電子メールアドレスがある公開鍵と関係する」となっています。また、「同一性の証明が必要とされない」場面での利用を「適当」としています。つまり、識別名(=本名とは限らない)・電子メールアドレスと公開鍵との対応は保証するけど、それが誰なのかということまでは面倒見ないよ。と書いてあるわけです。これを真似したのかどうかは判りませんが、このクラス1相当の認証レベルを、あろうことか組織にまで拡張してしまった認証機関が存在し、いまもせっせと証明書を発行し続けているのです。 ちなみに、私が調べた範囲では、「クラス3の認証」といううたい文句はいくつかの認証機関で見つけられましたが、「クラス1の認証」と明記している認証機関はありませんでした。
ここで少し疑問なのは、、なぜ原始レベルとかクラス１相当の、無保証のサービスが存在するのかというとです。ぱっと思いつくのは、無保証タイプの証明書は安く、クラス3相当の保証を伴う証明書とうまく棲み分けている、という筋書きですが、クラス3認証を明記した、年間1万円以下の発行機関を見つけてしまい、この予想は外れてしまいました。今のところは、これまで書いてきたような証明書の種類に関してほとんど認知されていないため、淘汰がうまく進んでいないのではないかと考えています。もし理由をご存知の方が読んでおりましたら教えてください。
さて、この警告は出ないにもかかわらず信用のおけないSSL証明書、この世から淘汰されれば良いのですが、今すぐというわけにはいきません。そもそも、私には計り知れないニーズがある可能性も0ではありません。じゃあ何とか私の身の回りから排除しようと考えたわけですが、これがなかなか難しいようです。難しい理由はいくつかあるのですが、順を追って説明します。まずは、認証局証明書の問題についてです。
左の図は、利用者としての立場からすると、現状では一番好ましいタイプの認証機関の証明書リストです。認証局の発行する証明書のクラスごとに、認証局証明書が準備されています。ここで、「俺はクラス1の認証については信じないぜ！！」と思ったら、そのクラスの証明書を削除すればよいのです。と書けば済む話だったら幸せなのですが、そうもいきません。実はこの名前、認証局が勝手につけている名前で、「Class 1 ...」という名前の認証局証明書がClass 1の証明書の発行だけに利用されているという保証は、実はどこにもありません。この会社のCPSをざっと読んでみたのですが、そういう記述はついぞ見つけることはできませんでした。ただ、証明機関側に、そうした期待を裏切る理由はまったくありませんので、そういう期待をしても問題ないでしょう。あと、謎の「Class 4」という文字列が見えるのも非常に気になります。その機関のCPSにはClass 4に関する説明はありませんでした。利用者の不安を煽ってどうしようというのでしょうか。
一方、右側の図にはいくつかの機関の認証局証明書が並んでいます。見ただけで頭が痛くなってきますね。鋭い方はもうお気づきかと思いますが、発行する証明書の種類とその名前付けは、ポリシーとして各認証機関が独自に決定することになっています。つまり、「Classs 1」という名前で、実在証明を含むようなクラスの認証もありうるわけです。つまり、各認証機関の認証局証明書が信頼できるかどうかは、それぞれの認証機関のCPSを読んで、その機関がどういう認証レベルで証明書を発行しているのかを理解し、それぞれの認証局証明書を信用するかどうかという選択をしなければなりません。
話はこれだけでは終わりません。ある業者は、無保証タイプと実在証明付きタイプの2種類の証明書を発行していますが、認証局証明書は1つしかありませんでした。非常にいやな予感がします。
次に、ブラウザの一般的な問題について書くつもりだったのですが、調べているうちにブラウザではいまのところどうしようもない気がしてきました。当初は、
ブラウザがすべての証明書をフラットに扱ってるのは問題だ。認証レベルごとに管理して、例えばレベル1の認証を経て発行された証明書については、警告を出し、レベル2以上なら無警告とかいう実装にすればよいという趣旨のことを書こうと思っていたのですが、実はそういう実装は現状無理そうです。
上の図はある証明書のプロパティなのですが、「証明書の目的」に関する情報はあっても、「どの認証レベルで発行されたのか」ということに関する情報はどこにもありません。よくよく考えると、ポリシーは認証局が個別に決めてよいことになっているのでブラウザ側でどうしようもないのは当然といえば当然です。
さて、一般的にはブラウザでできる対策はなさそうなのですが、それとは別に Windows XP の Internet Explorerには、ここで取り上げているシナリオに関して、非常に深刻な問題があります。この問題は2002/05/02に高木さんによって指摘されているのですが、XPのIEでは、
デフォルトでインストールされている「信頼されたルート証明機関」は、どれも削除不可能となっているのです。つまり、利用者が自分の意思で「この認証局証明書は信頼できない」と判断して削除したとしても、Windowsが勝手に証明書を再インストールしてしまうのです。2005年の7月19日のWindows Update済のWindows XPでも、この仕様に変更はありませんでした。これでもし詐欺の被害に会う人が出たら、Microsoftはどう責任を取るのでしょうか? ちなみにMicrosoft等が証明書の採用基準としているWebTrustは、
取引内容の開示、取引の正確な実施及び個人情報保護のための内部統制について、公認会計士がWebTrust原則及び規準に照らして監査し、問題がなしと認定した企業に対しWeb画面にWebTrustシールを付与するもの
SECOMのニュースリリースより引用といったもので、認証局の証明書発行ポリシーに関してはノータッチです。
◆ 対策は?
非常にむずかしいです。おわり。という訳にもいきませんね。
ものすごく大きいレベルで言うと、認証機関で
- 認証レベル別に認証局証明書を発行する
- 認証レベルに関して基準を設け、認証局証明書の必須項目とする
という形に証明書のフォーマットを変更し、ブラウザでは認証レベル別に管理できるようにする。といった具合に、認証機関と開発者の間で協力し合って、ユーザーの利便を図るということが今後は必要になってくると思います。
利用者にいまできる対策としては、
- 正しいURLを知っているなら、高木さんの指摘した3項目を徹底する。ただ、目を皿のようにして「O」と「0」を見分けようとするよりは、錠前アイコンをクリックして、証明書にサインしている認証局の証明書が信頼できるかどうか確かめたほうが早いような気がします。
- 正しいURLの記憶が怪しい場合、クレジットカード決済は避ける等、危険な情報のやり取りを避ける。
- 正しいURLの記憶が怪しい上、どうしてもクレジットカード決済が必要な場合、認証局のCPSまでさかのぼって、信頼できる発行ポリシーに基づいて発行された証明書かどうか確認する。
といった感じでしょうか。めんどくさいですね。
Internet Explorerの利用をやめて、いったんすべての認証局証明書を削除し、警告が出るたびに判断して再登録していく。といった手法も考えられます。サンプルを書こうとしたのですが、Firefoxで認証局証明書のバックアップを取る方法がわかりませんでした。この仕様はいただけないなぁ。
2005-07-31 [長年日記]
◆ お仕事
なかなかシャレにならない事態が発生して、徹夜でお仕事。以前はややナンセンスだった想定が、現実になっていてちょっとびっくり。技術が発達した弊害なのか、それしか手が残っていない状況まで相手を追い込んでいるのか。後者であればよいんだけどなぁ。
◆ 日曜大工
いきなり思い立って夕方前から行動。なかなか良い出来。
◆ F１ハンガリーGP
久しぶりに深夜の地上波で。森脇、右京ペアのおかげか、もしくは日曜大工しながら見たからか、だいぶましになってたような。大事なところ飛ばしてたような気もしますが。ともあれ、琢磨おめでとう。このままじゃ来年のシート怪しいので、今後もポイント稼いで欲しいものです。トヨタは来ましたね。サーキットと相性良かったのかな。シュー兄は車の自力が上がったのか、作戦の勝利か微妙ですね。アロンソがノーポイントでミカキミ優勝ということで、タイトル争いもなんか面白くなってきました。
P.S.
先日密かにチケット探したんですが、どこも売り切れでした。うーむ、一時期の悪夢の再現か。
◆ upload.rb
最新のtDiaryでは動かないという報告をパッチとともにいただいているのですが、検証してる暇がありません。パッチを頂いた方には申し訳ないのですが、性格上、および日ごろいろいろ書いている手前、ちゃんと自分で理解してからと思っていまして。。。
そのパッチを送ってくださった方が、最新のtDiaryに対応した私家版 を公開してくださっているので、すぐに使いたいという方は、そちらをどうぞ。
tDiary本家あたりに、プラグイン作成者向けのCSRF対策に関する説明があると嬉しいんだけどなぁ(ぼそっ)
- taru_k [やってきのたがキレンジ研?]
- hs [山田く〜ん 座布団全部取り上げて。]