2007年10月30日
昨日、専修大学にリチャード・M・ストールマンが来日するということで、
（時間があったのと、私が割りと近くに住んでいる関係から）行ってきました。
http://www.senshu-u.ac.jp/School/network/news/event/rms.html
RMSは言わずと知れた（？）
1985年にFree Software Foundationを設立した人物です。
リチャード・ストールマン [Wikipedia]
今のようにオープンソースもとい、フリーソフトウェアが普及するようになる
遥か昔から活動されている、この界隈の教祖のような人です。
# 本当に教祖だったり…
上記は彼自身のネタですが、実際に生で見れて笑えました。
（Wikipedia中にこのネタも書いてあるとは。Wikipedia恐るべし。聖イグヌチウス）
ちなみに私はvi派ですので、彼の所には入信できなそうです（笑）。
"フリーソフトウェアはオープンソースと違います（by RMS）"の詳細へ»
2007年10月25日
IPAによると、ウェブサイトの脆弱性で300日以上も対策が完了していないものが
50件にも達しているそうです。
ソフトウエア等の脆弱性関連情報に関する届出状況 [2007年第3四半期（7月〜9月）]
http://www.ipa.go.jp/security/vuln/report/vuln2007q3.html
関連：300日以上脆弱性が修正されないWebアプリが累計50件、IPA
http://www.atmarkit.co.jp/news/200710/22/ipa.html
リンク先のグラフを見ると、やはり多いのが「クロスサイトスクリプティング」。
次いで「SQLインジェクション」。
これらは簡単に直せそうで直せなかったりするあたり、嫌な脆弱性です。
どこも対応に苦慮している、というところでしょう。
また、届け出件数合計152件のうち、103件がWebアプリケーションに関するものだった
ということです。この要因は幾つか考えられます。
要因1. 多くのシステムがWeb化しているため
要因2. 単純に攻撃対象がWebアプリケーションにシフトしているため
要因3. Webの脆弱性は比較的発見しやすいものが多いため
ただし、要因3は「クロスサイトスクリプティング」や「SQLインジェクション」などに限った話です。
これらはゴキブリの如く撲滅するのは大変ですが、見付けるのは簡単です。
何故なら現象が目に見えるからです。多くはパラメータなどにコードを入れてみると発現します。
一方で、矛盾する話ではありますが、Webの脆弱性であっても発見しにくいものは多く存在します。
「レスポンススプリッティング（response splitting）」、
「リクエストスマグリング（request smuggling）」、
「クロスサイトリクエストフォージェリ（CSRF）」…など、聞いたことはありますか？
上記の脆弱性のように複数のサイトに跨るものや、キャッシュサーバなどを悪用するものは
実際にはレアケースではありますが、現象からは発見しにくいものです。
こういう小難しい脆弱性もありますので、
修正が長期化する前に、専門家に任せましょう。
彼らはよくあるポイント（コツ）を知っていますので、必ずや発見、
適切な解決のためのアドバイスをしてくれるはずです。
適材適所。開発者がテストを兼ねてはいけないという事と同じで、
セキュリティについても開発者がチェックを兼ねてはいけません。
"修正されない、Webの脆弱性…"の詳細へ»
2007年10月12日
三部作完結編。
ユーザ編、運営編、と来ましたので、最後は開発編です。
今となってはかなりメジャーな脆弱性なため、Web系・非Web系問わず、
多くの開発者がクロスサイトスクリプティングについて知っていることでしょう。
なので、ここでとやかくは言いません。
開発の場でクロスサイトスクリプティングに対する施策と言えるのは、
・Validation（入力チェック）による制限
・Sanitize（変換処理）による無害化
・フレームワークによるコードの強制
あたりでしょうか。
当り前すぎてだからなんだと各方々から言われそうですが、
3つ全部実施していますか？というと、意外とやってない様な気がします。
この文字列は入力チェックをしていて、この時にこの文字が表れるわけがないから……とか
表示するときに全部変換処理しているはずだから……とか
きっとフレームワークは凄いから、対策してくれているにちがいない……とか
意外とありそうです。
実際には、個々の要素がしっかりしていて結果として問題ない場合もあるのですが、
昨今の状況を鑑みるに、二重三重の対策をすることも考慮すべきです。
ちょっと自衛策とはちがうかもしれませんが、こんな感じでまとめてみました。
あなたはどこに属してますか？きちんと対策してますか？
"クロスサイトスクリプティングの自衛策（開発編）"の詳細へ»
2007年10月10日
クロスサイトスクリプティングの話の続きです。
前回がユーザ編と題して、エンドユーザの自衛方法を紹介しましたので、
今回は、運営側の自衛手段の紹介です。
Webサービスの提供元は、ユーザが安心してサイトを利用できるように、
クロスサイトスクリプティングを始めとしたWebアプリケーションの脆弱性に対応する必要があります。
一般に、クロスサイトスクリプティングの脆弱性、というと、
「クッキーがどうたらで、ユーザアカウントが乗っ取られるんでしょ？」
と認識されていて、
「うちはクッキー使ってないから」とか「そもそもログインとか無いから」とかで
「うちは問題ない」という間違ったリスク分析が行われています。
クロスサイトスクリプティングの脅威は多角的で、かつ技術的に難しい話になりがちなので
こういった誤解があるのしょう。
クロスサイトスクリプティングの脆弱性は、例のGmailのように、
「(1) セッションクッキーを盗み、ユーザになりすまし、機密情報を盗むケース」
もありますが、私が最も恐ろしいと考えているのは、
「(2) スクリプト等による動的なページの改竄」です。
ページの改竄によって、起こりうる重大な問題はフィッシング詐欺です。
大分フィッシングという言葉は一般的になったため、細かい解説はしませんが、
フィッシングの恐ろしさは、その手口の自由度にあります。
通常、一つの脆弱性による影響は一つですが、フィッシングの影響は多々あります。例えば、ログインページがあるサイトではユーザIDやパスワードが盗まれる可能性がありますし、ショッピングサイトでは、クレジットカード番号が盗まれる可能性もあります。情報を盗むだけでなく、あたかもその当該サイトのように振る舞うことで事実とは異なる情報を流したり、マーケティングやブランディングにも影響を及ぼすこともあります。
クロスサイトスクリプティングの脆弱性が存在すると、何が起きるかわからない不安が付きまとうのです。
というわけで、サイト運営者であるあなたの首が飛んだり、誰かの責任問題に発展する前に、
自衛策を取っておきましょう。
根本的な対策方法は、「サイト開発者にクロスサイトスクリプティングの脆弱性を作りこませない事」ですが、バグの無いソフトウェアは存在しない、という経験則や、Googleでも作りこんでしまう程の問題ですからなかなか難しいところです。
私の推奨策は、Webアプリケーションファイアウォール（WAF）の導入です。
クロスサイトスクリプティングはWebアプリケーションの脆弱性の中でも、セッション管理系などの脆弱性と比べても単純なものであるため、アプリ側ではなくシステム側で対処することで根こそぎ脆弱性を断ち切ることができます。
# WAFというと、設定や運用が大変というイメージが一部では存在するのですが、
# 弊社のWAFであるnetfireは、簡単な設定で運用が可能でご好評いただいています。
1匹見付けたら他にも100匹いるようなゴキブリと同じく、
クロスサイトスクリプティングも1箇所みつけたら…、です。
包括的な対策として、WAFが最も有効な手段と言えるでしょう。
"クロスサイトスクリプティングの自衛策（運営編）"の詳細へ»
2007年10月02日
Gmailにクロスサイトスクリプティングの脆弱性が発見されたそうです。
グーグル、「Gmail」の脆弱性を修正（CNET Japan）
http://japan.cnet.com/news/sec/story/0,2000056024,20357588,00.htm
Gmailでは度々（インパクトが比較的大きいためニュースに取り上げられる事が多い）
脆弱性が発見され、都度修正されていますが前回発見された時もクロスサイトスクリプティングだった気がします。（CSRFだったかな？）
逐次システムが更新されているGoogleでもクロスサイトスクリプティングの脆弱性をしこんでしまう位、クロスサイトスクリプティングは潜在化しています。以前、インターネット上のサイトの約80%にはクロスサイトスクリプティングの脆弱性がある、という調査結果がありましたが、現在に至っても現実問題としてまだ多くのサイトにクロスサイトスクリプティングの脆弱性が存在する可能性が高いと感じています。（恐らくは、今調査してもパーセンテージは変わらないでしょう…）
基本的にこの問題はサイト運営者側の問題のため、運営側が修正を行わない限り根本的に解決しません。これは、クロスサイトスクリプティングに限った話ではなくWebアプリケーションの脆弱性全般の話ではあります。
そういうわけですが、ユーザ側としても対策されるまで指を加えて見ているわけにはいきませんので、
自衛策が必要です。そこで、私のオススメは、Firefoxの拡張機能である、
NoScript
https://addons.mozilla.org/ja/firefox/addon/722
です。機能一覧はサイトを見てもらうことにして、メインはホワイトリスト機能です。
基本的に、すべてのサイトでJavascript等の実行を不許可にし、Gmailなど特定のサイトだけJavascriptの実行を有効にして使います。ただし、こういったJavascriptの有効/無効を切替えるブラウザは幾つか存在しますが、これだけではクロスサイトスクリプティングは防ぐことはできません。
NoScriptがユニークなのは、クロスドメインへのPOSTの抑制機能があるところです。（たとえば、www.brain-gate.net（スクリプト許可）からwww.netfire.jp（スクリプト不許可）へのPOSTリクエストを送った場合、データ部分が削られる。）これによって、多くの場合クロスサイトスクリプティングの実行を阻止できます。
あくまで自衛策であり、盲信してはいけませんが
NoScriptを使うことで比較的安全にWebブラウジングが可能になります。
Firefoxを使っていない方は…？
頑張ってください（苦笑）
"クロスサイトスクリプティングの自衛策（ユーザ編）"の詳細へ»
