2008年11月4日(火曜日)
安全なWebブラウザの使い方
更新: 2009年5月31日23時55分頃
「JPCERT/CC、技術メモ「安全なWebブラウザの使い方」を公開 (internet.watch.impress.co.jp)」。JPCERT/CC 技術メモ (www.jpcert.or.jp)でPDFがダウンロードできます。
これはすばらしい良書ですね。なぜなら、「Netscapeを使うな」という主旨のことが書いてあるからです。名指しでないのが残念ですが。:-)
それはそれとして、すこし気になった点をいくつかメモしておきます。
8ページ目。
SSL 2.0 には実装上の脆弱性があります。SSL 2.0 のみでしか利用できない Web ページはほとんど存在せず、またサポートしている暗号のアルゴリズムも古いため、ブラウザの設定で無効化して使わないようにすべきです。
実装上の脆弱性なら、脆弱でないように実装すれば良いだけのように思えますが……。
実際には、これは仕様上の制限だと思うのですが、どうなのでしょうか。中間者が暗号強度をダウングレードする攻撃が有名ですが、SSL2.0の仕様にしたがって実装する限り、これを避けることはできないのではないかと思いますが……。
※参考: SSL 2.0 と輸出強度暗号 (www.oiwa.jp)
それから9ページ。
この章では、前章で述べた注意事項に対応する、個々の Web ブラウザでの具体的な設定方法を、主なWebブラウザについて説明していきます。
と言いながら、
[ツール]→[インターネットオプション]→[セキュリティ]→[Web コンテンツのゾーン*を選択してセキュリティのレベルを設定する] →[インターネット] / [イントラネット]/ [信頼済みサイト]/ [制限付きサイト]を選択 →[既定のレベル]を選択する、もしくは[レベルのカスタマイズ]で各種スクリプトごとにゾーンごとの信頼度に応じて有効/無効/確認を求める等を選択する →場合によって[信頼済みサイト]/ [制限サイト]のそれぞれのゾーンごとに、Web サイトの信頼度に応じて、URLを[追加]/[削除]する
「場合によって」「信頼度に応じて」って……どのあたりが具体的なのでしょうか。どのゾーンにどのセキュリティレベルを適用すれば良いのか、具体的にわからないと設定できないと思います。
また、デフォルトでスクリプト無効にしましょう、という旨のことは書かれているのですが、有効にしたいときにどういう運用をすれば良いのか分かりません。信頼済みサイトゾーンを利用する想定なのであれば、信頼済みサイトゾーンのセキュリティレベルを「低」のままにしないように注意する必要があるでしょう。
※この作者はIEを使っていないのかもしれないなぁと思ったり。Firefoxの設定はけっこう充実しています。
※2009-05-31追記: スクリプトを無効にして運用するのは大変なので、普通の人にはあまりオススメしたくないですね。「スクリプト無効は万人にオススメできるのか」参照。
22ページ。
不特定多数によって書き込みが行われる掲示板・ブログ等の Web サイトでは、極力リンクをクリックしない方がよいでしょう。どうしてもリンク先にアクセスしたい場合は、リンクをクリックする前に、カーソルをリンクの上に移動し、ステータスバーなどでアクセスしようとしている URL を確認し、信頼できるドメインかどうかを十分に吟味した上でクリックして下さい。
(～中略～)
表示と参照先URLが異なる、単純な HTML 上の表示の偽装への対策は、上記②の対策で紹介したステータスバーなどによる確認が良いでしょう。しかし、一部 Web サイトでは JavaScript 等によってステータスバーに表示される URL を置き換えている場合があります。これを防ぐにはスクリプトの実行を一旦制限した上で URL を確認する必要があります。
そこで攻撃者はリダイレクタを悪用するわけですね。:-)
アクセス前にリンク先のURLを確認する、という手法には限界がありますし、これを素直に実践すると、リンクをクリックするたびに「スクリプト無効にする→URLを確認する→クリック」としなければならないのですが、それは現実的なのでしょうか。「悪意あるサイトにアクセスしないように気をつける」というより、「既に悪意あるサイトにアクセスしているかもしれないという前提で行動する」という方が良いようにも思いますが。
これに関連して、24ページ。
HTTPS による暗号化通信が行われている Web ページでは、SSL サーバ証明書に問題がないことを確認することが重要です。Web ブラウザは証明書の検証を自動で行い、失敗した場合には警告を表示します。警告が表示された場合には、速やかにそのWeb ページの閲覧を中止してください
これはまあ良いのですが、そもそもHTTPSによる暗号化通信が行われていないサイトに入力フォームがあった場合にはどうしたら良いのでしょうか。HTTPSのときだけ気をつけて、HTTPSでないページでパスワードや個人情報を入力してしまったら意味がないような気がしますが、それはどこにも書かれていないのですよね。
※まあ、事情があって書けなかったのかもしれませんが。:-)
- 「安全なWebブラウザの使い方」にコメントを書く
関連する話題: セキュリティ / Web / Internet Explorer / Firefox / JPCERT/CC
ナイチンゲールの沈黙
公開: 2024年4月24日19時30分頃
読み終わったのでメモ。
- ナイチンゲールの沈黙 上 (www.amazon.co.jp)
- ナイチンゲールの沈黙 下 (www.amazon.co.jp)
前作 (www.amazon.co.jp)
キャラクターは魅力的だと思うのですが……。
うーん、なんというか、これ、ミステリと思って読んじゃダメなのかもしれないですね。
以下、ややネタバレ気味な上にネガティブなコメントになりますが……。
ミステリとしての素材としては「殺人」と「歌の謎」という2要素があるわけですが。
まず殺人の方は、フーダニットとしては成立していませんし、ハウダニットではありませんし、あえて言うとホワイダニットなのでしょう。が、その結論を読んでも「なんとそうだったのか!」とか「やっぱりのそうか!」といった感じではなく、「へえ、そうですか」としか思えなかったというのが悲しいです。奇抜なトリックも意外な動機も何もありませんし……。あるいは社会派なのかと考えてみても、登場人物のほぼ全員が「被害者は殺されて当然」と思っているようにしか思えないわけでして、警察は「仕事だから」という理由で犯人捜しをするだけなのですから盛り上がりようがありません。
殺人はオマケで、ミステリとしての本質は歌の謎にあるのだ……とも考えてみましたが、こちらはこちらで論理的な裏付けに乏しく、これまた「へぇ」としか言いようがないです。それも3へぇくらいです(古いな)。というか、これほとんどオカルトじゃないですかね?
※個人的に、ミステリにオカルトを持ち込むのはアンフェアだと思うのです。論理的に説明できるはずだと思ってあれこれ考えながら読んでいるわけですから、「超常現象でした」とか言われると本当にしらけます。三毛猫ホームズの騒霊騒動 (www.amazon.co.jp)
むしろ作者の意図としては、DMA (Digital Movie Analisys) の話をしたかったのかもしれないと思いましたが、これもなんか嘘くさく見えてしまって……。CTは物体を固定した状態で連続した断層写真を撮っているわけですから、それを3Dに展開できるのはわかります。が、ふつうに現場を撮影した (としか思えない) ムービーデータから、そんなに簡単に 3D モデルが起こせるものなのでしょうか。骨折の話から被害者の状態を推測するあたりとか、そんな一瞬で解析できると思えないのですが……。
というわけで、なんかミステリとしてはダメだと思います。ではどう読むべきかと言われると、なかなか難しいですが……前作のキャラのファンに対して、彼らの後日談をまったり描いた萌え的作品(?)……といったところでしょうか。前作は面白かったですし、キャラクターは魅力的だと思いますので、そういうものだと思えば満足できそうです。
※というか、前作 (www.amazon.co.jp)
連絡先がわかりにくいサイトは信頼性が低い?
公開: 2024年4月24日18時50分頃
「About Us ページのユーザビリティ (www.usability.gr.jp)」。
連絡先を見つける、例えば企業の主要な住所を見つけよといったタスクでは特に顕著な上昇が見られた。このタスクの成功率は62％から91％に上昇した。依然として、ウェブ上で連絡先を見つけることは実質的に不可能という企業もいくつか存在する。そしてあるサイトは、故意に住所や電話番号を隠しているようにも見える。けれども、そうすることは逆効果となろう。なぜなら、ユーザはそういうサイトを非常に信頼性の低いサイトとみなすからである。
脆弱性の届出時にはWebサイト運営者の連絡先を記載する必要があるのですが、それがなかなか見つからなくて困る事が多いです。
「脆弱なサイトは、連絡先がわかりにくい傾向にある」という相関関係があるような気がしてならないわけですが……そういう意味でも、「ユーザはそういうサイトを非常に信頼性の低いサイトとみなす」というのは妥当なように思いますね。
関連する話題: ユーザビリティ / 情報セキュリティ早期警戒パートナーシップ
死んでました
公開: 2024年4月24日16時55分頃
何故かbakera.jpのサービスが固まっている気配がしたのでIISの再起動を試みたら、再起動できず。
「サービス開始中」の状態で固まっていて、何度か再起動を試みたりプロセスを殺してみたりしたものの復活せず。
しようがないのでマシンごと再起動して復活しましたが、その間、1時間以上止まっていました。すみません。
※新システムが不安定? しかしIISが再起動できなくて固まるというのは、hatomaru.dllのせいではないと思うのですが……。
関連する話題: bakera.jp / hatomaru.dll
インクリメンタル名前解決
公開: 2024年4月24日15時20分頃
「[その他]自重しろ？＞クロム (d.hatena.ne.jp)」。
クロムの通信をモニタしてみたんだけど、URL直接入力のときに1文字ずつグーグルと通信してるんですね。
画像を見ると、一文字入力するごとにDNSキャッシュサーバに名前を問い合わせに行っているようですね。
※「グーグルと通信」は書き間違いで、「DNSサーバと通信」が正解なのかも。
Ajaxでインクリメンタルサーチなんてのも最近けっこうありますし、それ自体はユーザビリティ向上していると思うのですが、インクリメンタルで名前を引きに行くのは斬新というか、意味がわからないというか……。
関連する話題: 与太話 / DNS / Google Chrome
更新日時を更新
公開: 2024年4月24日14時10分頃
Atomのupdatedがテキトーすぎる問題に対応。各項目に対して手動で作成日・更新日を指定できるようにして、Atomフィードに反映されるようにしました。
直近のいくつかの項目についてはあらためて作成日時を登録しましたので、updatedの時刻が変更されています。つまり、「更新日時が変わり、更新されたように見えるが内容は変わってない」という残念なことが起きています。今回だけですのでお許しください。
今後は、作成時刻や更新日時がそれなりに反映される予定です。
※更新日時のデータを持つようになったので、「最近追記された日記一覧」なんてのも出せるようになりました。需要ありますかね……?
関連する話題: bakera.jp / hatomaru.dll
何かが足りない気がする
公開: 2024年4月24日2時55分頃
Aamzonで「プログラミングMicrosoft ASP.NET 3.5 (www.amazon.co.jp)
プログラミングMicrosoft ASP.NET 3.5 (マイクロソフト公式解説書 Microsoft Visual Studi) (単行本（ソフトカバー）)
よくよく見ると何かが微妙に足りない。
※書名長い……。
テキストデータとHTML断片を区別する
公開: 2024年4月24日2時45分頃
「出力処理のホワイトリスト (rryu.sakura.ne.jp)」。
以前に上記の方法と同じようなものを検討したことがある。エスケープ漏れが発生するのは、同じ変数の中味が処理の段階によって未エスケープからエスケープ済みに変わったり、未エスケープとエスケープ済みの変数が何の区別もなく混在しているからだという話をどこかで読んだためだ。
「安全なテンプレートシステムはあるのか」ですかね。型が同じなのが良くないのではないかという話であって、変数の名前で区別する話ではありませんが。
……ところで余談ですが、新しいhatomaru.dllでも「全部DOMでつくり、InnerXml/OuterXmlには書き込まない」というポリシーは健在で、XSSに対する特別な配慮はほとんどしていません。それは良いのですが、実は「全部DOM」方式にも弱点があることが判明しています。
C#でこんなコードを書くと……。
XmlDocument result = new XmlDocument();
XmlCDataSection CDATA = result.CreateCDataSection("<![CDATA[CDATAのサンプル]]>");
これは問題なく動作しますが、このCDATAのOuterXmlを参照したり、ドキュメントをSaveしようとすると例外が発生します。
System.ArgumentException: XML CDATA ブロック内部に ']]>' を含めることはできません。
DOM方式なら何が来ても大丈夫、というわけではないのですね。
興味深いのは、ノードを生成することはできていて、出力しようとしたときにはじめて例外になるという点。内部的には ']]>' を含むXmlCDataSectionのノードがちゃんと生成されていて、出力するときにはじめてエスケープ処理を行おうとしていることが分かります。
※で、CDATA区間の中の ']]>' をエスケープして表現する方法が存在しないために例外になるわけですね。問題の部分をCDATA区間の外に出すか、あるいはCDATA区間を二つに分割すれば表現できますが、ノードの数が変わってしまいますし……。
※そもそも、CDATA区間は基本的に「エスケープして書くのが面倒」という時に使うので、DOMでCDATAを生成する意味はあまりありません。script要素に中身を書こうとしなければOK。
- 前(古い): 2008年11月3日(Monday)のえび日記
- 次(新しい): 2008年11月5日(Wednesday)のえび日記
