水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2005年のえび日記 > 2005年6月 > 2005年6月15日(水曜日)

2005年6月15日(水曜日)

Whois怖い

「米国の話聞き、試してみた」　フィッシング容疑者供述 (www.asahi.com)という記事が。

同容疑者は勤務先の大阪市内のソフトウエア開発・情報処理会社で、コンピューターのシステム管理を担当。偽サイトは勤務先のパソコンから開設していた。偽サイトのドメイン（ネット上の住所）は「ｙａｆｏｏ．ｊｐ」で、４年前に業者から本名で取得していたが、サイトは開設しておらず、フィッシングをする直前に妹の名前に変更していたという。

逮捕された人の情報が Whois で公開されているのはまずいと思いますが、逮捕された人の妹さんの情報が公開されているのはもっとまずいのではないかと思いました。

関連する話題: セキュリティ / プライバシー

ニュースサイトのアクセス性

「ブログに問われる書く技術、話す技術 (www.itmedia.co.jp)」というお話が出ていますが、内容はさておき思ったこと。

大手ポータルがブログサービスを行なうようになってから、インターネットの景色は一変した。例えばサーチエンジンで何かのキーワードを引くと、記事元のニュースサイトよりも、それを引用したブログが先に来ることも珍しくない。

以上、ブログに問われる書く技術、話す技術 (1/3) より

確かに珍しくないですし、検索している側としても嬉しくない事態ですが、本来はそんなことは起きないはずなのですよね。普通、Web の記事を引用したら元の記事にリンクしますから、ニュースサイトの方がランクが高くて当然なのです。

にもかかわらず逆転現象が起きたりするのは、引用されるニュースサイト側のアクセシビリティに問題があるからなのだろうと思います。

たとえば、MSN-Mainichi INTERACTIVE (www.mainichi-msn.co.jp) のニュースなんかはかなり良く引用されると思うのですが、個々の記事を見ると、title要素にその記事の題名が入っていない、h1要素もないという状態です。

読売などはちゃんとタイトルが入っていますが、こちらはこちらでいわゆる「ディープリンクお断り」の姿勢を見せています (参考: http://www.yomiuri.co.jp/policy/link/ )。そのため、その意思を尊重する人は、引用はしても記事へのリンクはしないことになります。これまた当然ですがランク低下の原因となります。

ニュースサイト側に明らかに負けている要因があると思うのですよね。

関連する話題: アクセシビリティ

早期警戒パートナーシップの感想とか?

IT Pro にこんなのが出ていますね……「セキュリティ向上への地道な試み「早期警戒パートナーシップ」を知っていますか？ (itpro.nikkeibp.co.jp)」

さすがに最近ではベンダーの意識が高くなり，上記のような対応をするベンダーは少なくなったと感じている。多くのベンダーはセキュリティ情報や修正版（修正プログラム）を公表するようになっている。セキュリティ・ホール情報の受付窓口を用意しているベンダーもある。

以上、セキュリティ向上への地道な試み「早期警戒パートナーシップ」を知っていますか？ より

これはソフトウェア製品の話であって、ウェブアプリケーションの話ではないですよね。ウェブアプリケーションについては、現在でもユーザへの報告無しのヤミ改修が主流だと思いますので。

この制度では，セキュリティ・ホールの発見者が報告しやすい。開発者や運営者と直接やり取りしないので，無視されたり恫喝されたりする心配がない。犯人呼ばわりされる恐れもない。実際，この制度でセキュリティ・ホールを報告した経験がある方に話を聞くと，「直接連絡をとらなくてよいので楽だ」とのこと。その方は，この制度が始まる前から，ベンダーなどに何度か報告したことがある。具体的には聞けなかったが，直接連絡をとると，何かと苦労があるという。

以上、セキュリティ向上への地道な試み「早期警戒パートナーシップ」を知っていますか？ より

私個人の感想を付け加えると、複数のベンダに影響する問題について調整してもらえるのが非常にありがたいと思いました。たとえば、JVN#FCAD9BD8 (jvn.jp) の届出には Shuriken と Outlook Express の名前しか出ていませんが、公開時には他の製品もたくさん名を連ねていました。それらは IPA や JPCERT/CC の方が独自に調査して連絡してくださったものに違いありません。個人が大量の MUA を調達して検証するのは難しいですし、こういう対応をしてもらえるのはありがたいです。

※ただ、その過程の情報が届出者のところにぜんぜん来ないのはどうかと思います。「○○の開発者にも連絡しました」というような報告があっても良さそうなものだと思いますが。

もっとも、これまたソフトウェア製品に限った話なのでして、ウェブアプリケーションの方はまた別な感想があったりなかったり。

関連する話題: セキュリティ / 情報セキュリティ早期警戒パートナーシップ

メモ : URL にセッションが入ってしまっている場合の自衛策

「URLに埋め込むIDに頼ったセッション管理方式の脆弱性(2) － REFERER情報流出によるセッションハイジャック攻撃の問題 － (securit.gtrc.aist.go.jp)」という文書が出ていますが、URL にセッションを埋め込んでしまっているシステムをどうしても使わなければならない場合、ユーザの自衛策としては以下のような対応が考えられます。

こんな感じの対応をマニュアル化して周知する感じ?

要は URL がセッション情報を含んでいるということを意識して、それが漏れないように注意する必要があるということで。

関連する話題: セキュリティ

最近の日記

関わった本など