前半は「具体的な復旧方法」ということで、緊急対応が終わったあとの本格的な復旧フェーズの進め方のお話。月末の報告書作成といったような通常業務と復帰作業のどちらを優先させるか、など、実際にやっている人ならではの指摘が所々にちりばめられていて、よい勉強になりました。ケーススタディで謝罪やユーザに対する告知の文例があったのも良かったです。ただ一点、資料の中で「サイバーテロによる脅威」という文言に「米国多発テロで現実のものに・・・」という吹き出しがついていたのは謎。あの事件はサイバーテロとは違うんじゃ？？

後半は「xSPのセキュリティの未来」というテーマでのパネルディスカッション。まずパネラーの方々が、それぞれの立場からテーマについての自分の意見を述べた後、自由討論へ。インターネットの匿名性を悪用した犯罪にどう対処するか。開発者のスキルが上がらず、ソフトウェアの脆弱性がなくならないのはどういうことだ？脆弱性を発見した人と指摘を受けた組織はどう折り合いをつけていくのか。クレーム処理などについての議論のあと、最後に未来についての明るい展望をということで、一言ずつあって終了しました。

そのディスカッションの中で、数人のパネラーの方がセキュリティに関して適切な対価が支払われていない、という問題提起をし、安かろう悪かろう業者の問題や、客も委託先をきちんと評価した上で、よい仕事に対してはきちんと対価を払うようにしようよ、といった意見がありました。確かにそのとおりだとは思うのですが、そうした意識をパネラーの方々は自ら(あるいは自らが属する組織)にも適用すべきでは？などとちょっと（かなり？）偉そうな感想が首をもたげ、最後まで頭から離れませんでした。どういうことかというと、たとえばJPNICでは過去のセミナーの全ての資料や当日のビデオを公開しています。ここまですばらしいものがタダで、しかも主催者の手によって配布されるのなら、わざわざお金を払ってセミナーに参加する意味はあるのか？と思えてならないのです。MITのOpenCourseWareに触発されたにしても、ちょっとやりすぎというか。どこかで以前山口氏が、日本人はセキュリティがタダだと誤解していると言っていたと思いますが、そうした風潮を自ら作り出すようなまねしてどうする、と。また、講師やパネラーの方々が、職務上の立場や個人的な使命感から、結果としてボランティアするのはしょうがないとしても、それを公言するのにも違和感を覚えます。業界内の一流どころが、うまくすればタダでやってくれる仕事を、それ以外の人にお金を払って頼むでしょうか？この辺はプロスポーツの世界などとまったく同じ構造で、一流どころは絶対に自分を安売りしちゃいけないんだと思います。いや、受講者・相談者という立場からすればタダで情報が手に入ったり、低料金でセミナーを受けたり相談にのってもらえるということは大歓迎なのですが、この段の冒頭の話と、こういったことがどこか根っこで繋がっているような気がしてなりません。

駄目だ駄目だでは建設的ではありませんので、私がうまいと思った例を挙げておきます。USENIXのSecurity Symposiumでは、カンファレンス終了後１年間に限り論文と１件の招待講演の資料を公開しています(それ以降に閲覧できるのは会員のみ)。会場では各招待講演のアンケートが投票用紙もかねており、「この講演の資料の公開を望むか？」といった感じの質問があります。どうやら、その結果をもとに全講演の中から１件だけ公開することに決めているようです。アメリカ礼賛というわけではありませんが、有料セミナーであることの意味を失わせずに、かつ興味を引く方法としては、すごくうまいなあと感心したのでした。

[ツッコミを入れる]

2008-02-04

◆ [Ruby] ERB でのタグ出力を簡単かつ安全に

水無月ばけらのえび日記の「安全なテンプレートシステムはあるのか」を読んでふと思いついたアイデア。

require 'erb'
include ERB::Util

class Object

   def clarify
      raise SecurityError.new("Object is tainted.") if self.tainted?
      @clarified = true
      self
   end

   def unclarify
      @clarified = false
      self
   end

   def clarified?
      @clarified || false
   end
end

class ERB
   module Util
   public
      def h(s)
         if s.tainted? || ! s.clarified?
            html_escape(s)
         else
            s.to_s
         end
      end
   end
end

########## test ##########
SCRIPT = <<EOS
a.tainted?:   <%= a.tainted? %>
a.clarified?: <%= a.clarified? %>
h a:          <%=h a %>
EOS

a = '<SCRIPT>alert("!")</SCRIPT>'

print "-----\n"
print ERB.new(SCRIPT).result(binding)

print "\n-----\n"
a.clarify
print ERB.new(SCRIPT).result(binding)

print "\n-----\n"
a.taint
print ERB.new(SCRIPT).result(binding)

print "\n-----\n"
a.unclarify
print ERB.new(SCRIPT).result(binding)

print "\n-----\n"
a.clarify

実行結果はこちら

-----
a.tainted?:   false
a.clarified?: false
h a:          &lt;SCRIPT&gt;alert(&quot;!&quot;)&lt;/SCRIPT&gt;

-----
a.tainted?:   false
a.clarified?: true
h a:          <SCRIPT>alert("!")</SCRIPT>

-----
a.tainted?:   true
a.clarified?: true
h a:          &lt;SCRIPT&gt;alert(&quot;!&quot;)&lt;/SCRIPT&gt;

-----
a.tainted?:   true
a.clarified?: false
h a:          &lt;SCRIPT&gt;alert(&quot;!&quot;)&lt;/SCRIPT&gt;

-----
t.rb:6:in `clarify': Object is tainted. (SecurityError)
        from t.rb:60

解説すると、Objectクラスに「汚染」フラグとは別に「浄化済み」フラグを設け、そのObjectが汚染されておらず、かつ浄化済みであれば変数の内容をエスケープせずに出力するようERB::Util::hを再定義しただけ。エスケープを抑制する条件を単に tainted? == false としないのは、事の発端であったプログラマにセキュリティを意識させるための工夫のつもり。

taintも再定義して中で @clarified = false したいんですが、そこまでは腕がありません。あと、clarified?の「|| false」とかも@clarifiedの初期化の仕方がわからず、ひよった結果です。

あと、名前はsanitizeにしようかとも思ったのですが、さすがに自重。

[ツッコミを入れる]