佐藤康光棋聖が婚約
- 佐藤康光棋聖の婚約のお知らせ
- 佐藤棋聖が26歳ＯＬと婚約・８月に挙式（NIKKEI NET 将棋王国）
- 佐藤康光応援ページ「紳士棋士ドットコム」
佐藤康光棋聖が婚約だそうです。おめでとうございます。日本将棋連盟サイトでの発表はまだのようです。（2月10日：追加しました。）
金子タカシ氏の著作で好きなのは？
棋書ミニ投票＠将棋 棋書ミシュラン！第17回のお題は「金子タカシ氏の著作で好きなのは？
」。
下3冊は読みたいと思っても入手が難しいですが、やはり定評のある『寄せの手筋１６８』にしておきます。MYCOM将棋文庫で復刊したら売れるんじゃないかと思うのですがいかがでしょう。＞誰
詰将棋解答選手権戦
以前にも紹介した大会です。詳細は、詰将棋解答選手権戦要項をご覧下さい。出題者は若島正氏と山田康平氏。このお二方の新作が解けるだけでも価値があります。ただ、出題者は解答に参加できないというのは、当然ですが少し残念です。
それとは関係ありませんが、コーヘイ天国の乱！で例の大きな盤での初形曲詰「2004」の解答が発表されています。解いていない方は一度見てみてはいかがでしょう。
ゴーストライター
ゴーストライターを使って書いた本といっても、その本の内容のほとんどすべては、間違いなく著者の方の意見であり、見解なのである。
プロ棋士が書いたことになっている定跡書でも、実際にその棋士が全てを書いていることは少ないと言われています。例えば日本将棋連盟から出版されている本は、目次の裏側などの目立たないページに「編集協力」というクレジットが入っていることがあります。私はこれが「ゴーストライター」の役割を果たした人なのだと思っています。
実際には、それぞれの本によってどれくらいの仕事を任されているかは異なるでしょう。ある場合にはただの編集者でしかないかもしれませんし、ある場合には関係のある棋譜を洗いざらい探してきたり不明な変化について他の棋士に質問するようなことをしているかもしれませんし、ある場合には本に載せる変化の細部まで書いているかもしれません。
このように将棋本には、ほとんど全て棋士当人で書いているものから、ほとんど監修しているだけのものまでいろいろあります。よくある誤解に、棋士が自分で書いていないからだめだというものがありますが、上で紹介した文章を読んでいただければ、それが誤りであることに気付いていただけると思います。
将棋の棋士は将棋の強さを競っているわけですから、文章がうまいとは限りません。むしろ文章のうまい棋士は例外的な存在と思った方が良いでしょう。そのような背景を考えると、将棋本を作る上で編集者の役割は非常に大きなものになると言えます。文章や構成に関わることはもちろん、個々の手順などをより洗練されたものにする上で、編集者が有能かどうかは読者にはっきりと伝わります。
現在最も有名な将棋本編集者は浅川書房の浅川浩氏です。一つのブランドを作り上げつつあると言って良いでしょう。著者と編集者の力が組合わさって調和が取れていることが、名著の条件だと思います。
はてなダイアリーでJavaScriptが発動した（過去形）
2月8日の続き。
1月9日に長々と書いたように、はてなダイアリーはセキュリティを保つため様々な対策を行っています。その一つがはてなダイアリーXSS対策です。
昨日書いた脆弱性の内容を一言で言うと、はてなダイアリーの引用に関する機能でここで示された手順が守られていない部分があったということになります。具体的には第3段の次の箇所です。
href,src,cite,background 属性で外部 URL が参照される場合、URL が適切な文字で構成されているかチェックを行ないます。
2月7日に書いたように、はてなダイアリーでは引用の際に自動的に引用元にリンクを張る機能があります。この自動的に生成されるリンクで、上のチェックが行われていませんでした。そのため「JavaScript:」で始まるURIも通ってしまい、結果的にJavaScriptが利用できることになります。はてなでJavaScriptが利用できるというのは、そのページを閲覧した他のはてなユーザのアカウントを奪取できるということとほぼイコールです。
そのような可能性に気付いて、試し、実際にJavaScriptのアラートボックスが出現したときには、非常に驚きました。そして、しばらくしてからセキュリティ的に問題があることに思い当たりました。試していたのは過去の日記上でしたので、見る人は少ないだろうとはいえ自分以外にJavaScript発動を目撃した人がいる可能性がありました。だとすると早急にはてなサイドに知らせる必要があるだろうと思い、あわててメールを書きました。あせっていたため、どこにメールすべきかいろいろなところを見たもののよくわからず、結局info@hatena.ne.jpあてにメールするまでに10分以上かかってしまいました。人間混乱すると何をすべきかわからなくなるものです。
はてなダイアリー上でアラートボックスを見るのはもちろんこれが初めてでしたし、最後であってほしいと思います。この脆弱性は8日にすでに修正され、現在は安全なものになっています。すばやく対応して下さったはてなの近藤さん、そしてこれを発見するきっかけを作って下さり脆弱性の追試もして下さったhoshikuzuさんに、改めてお礼申し上げます。
脆弱性の発見と通報
今回私は脆弱性を見つけるという経験をしたわけですが、はてなダイアリーのセキュリティを追及していて見つけたわけではありません。そのきっかけは全くの偶然でした。
一昨日、私はhoshikuzu | star_dust の書斎 2月7日分で書かれた引用機構に関する文章に興味を持ち、blockquote要素に関することなどについて調べて2月7日の文章を書きました。しかし、それ以外に不明な点があったためもう少しいくつかのことを試していたのです。
不明な点とは、「cite属性が消える」というhoshikuzuさんの指摘でした。これまで書いた引用部分などを見てみるとcite属性が消えるようなことは確認できませんでした。しかし、hoshikuzuさんが示された例を試してみると確かにcite属性が消えます。例文を少しずつ変えながらテストした結果、これはcite属性にurn:isbn:で始まるURIが指定されていたことが原因であることがわかりました。その代わりにhttp:で始まるURLを指定すればcite属性が消えることはありません。その違いは何かというと、はてなダイアリーではURIの始めに来る文字列が特定のもの以外禁止されており、urn:isbn:は許可されていないということにあるということがわかりました*1。
しかし、そこで私は疑問に思いました。私もcite属性にurn:isbn:を指定したことが何度かあります。そして、それが正しく機能していないことには気付いていませんでした。なぜ気付かなかったのかというと、引用の際にはてなダイアリーが自動生成するリンク先にurn:isbn:で始まるURIが出てきているのが見えていたからです。
本来許可されていないはずのurn:isbn:が使えるなら、他のものも使えるのではないか。例えば、JavaScriptも……。という考えにたどりつくのには、もはや時間はかかりません。
セキュリティとは何の関係もなかったはずの、引用についての話が脆弱性発見につながった経緯がおわかりいただけたでしょうか。本来決められたステップが実装において省略されていたためにこのような脆弱性が出現してしまいました。決められた手順そのものが誤っていたわけではないという点で、深刻なものではないと言えるでしょう。
さて、私はセキュリティに関して特別な技術を持っているわけではなく、また特別に脆弱性を発見するよう努めていたわけでもありません。セキュリティ関係の話題はときどき読んでいましたが、小さなこととはいえ自分が当事者になるとは全く思っていませんでした。そんな状況でも場合によっては脆弱性を見つけてしまうことがあるということです。私がこういう経験をしたわけですから、次はここを読んでいるあなたの番かもしれません。
たまたま、はてながセキュリティに敏感で報告に誠実に対応することを私が知っていたため、見つけてすぐにその内容をメールすることができました。しかし、一般の業者の場合にはそうはいかなかったかもしれません。今回私が見つけたような脆弱性であれば、不正アクセスとみなされる可能性はありませんが、業者によってはそのことを理解せずにサービスに悪評を立てようとしていると誤解するかもしれません。また、業者にセキュリティに関する知識がなければ、対策を行うことの必要性をわかってもらえないかもしれません。
もしわかってもらえなかった場合どうするのか。難しい選択を迫られる事になります。例えば、次の3つが考えられるでしょう。
- わかってもらえないので、それ以上何もしない。そのサービスに脆弱性があることには口をつぐみ、脆弱性はそのまま放置される。
- セキュリティに対する脅威であることを伝えるため、アカウント奪取ができることなどを具体的手順で示す。
- その業者にわかってもらえないなら、せめてユーザには伝わるように脆弱性の内容を一般に公表する。
1.は業者にとっては一時的に都合がいいかもしれませんが、ユーザにとってはたまったものではありません。悪意を持った別の人物がその脆弱性に気付けば、当然悪用するでしょう。そもそもすでに悪用されていないという保証もありません。とはいえ、現状ではこれしかないのかもしれませんが。
2.で何とかなればいいと思いますが、現実には手順を文書で示しただけでは納得してもらえないこともあるようです。だからといって、アカウント奪取を実演してしまえば不正アクセスになってしまいます。
3.に近いことも検討されて然るべきだとは思います。具体的にどのような手続きを踏むべきかとなると、現状ではなかなか難しいようですが。
このように、脆弱性を抱えた業者がセキュリティに関して理解が乏しい場合、八方ふさがりの状況になりかねません。私なら初めから通報せずに自分だけ被害を受けないような方策を考えると思います。先ごろ逮捕されたoffice氏はこのジレンマを感じる場面が多かったようですね。あの事件*2は脆弱性通報に関して大きな影響を与えつつありますが、今後どうなるかはまだ不透明です。
脆弱性に接するのは「ハッカー」だけではない、全ての人が関わる可能性があるというのはよく言われることですが、今回改めて認識を新たにしました。脆弱性を見つけてしまったらどうすればいいのか。私にはよくわかりませんが、はてなのように理解のある業者相手でなくてもスムーズにことが運ぶようなガイドラインが求められます。
直接の関係はありませんが、さきほどhttp://slashdot.jp/article.pl?sid=04/02/08/1355209を読んで少し和みました。
*1:はてなダイアリー利用可能タグによると、現在許可されているのは次の6つです。http, https, ftp, mailto, rtsp, mms.
*2:ACCS不正アクセス 京大研究員逮捕事件のテンプレや「ACCS個人情報漏洩者 逮捕事件を私的に考える」がよくまとまっています。
