高木浩光＠自宅の日記 - EV SSLを緑色だというだけで信用してはいけない実例
■ EV SSLを緑色だというだけで信用してはいけない実例 EV SSLに関して以前から懸念されていたことが既に現実になっていた。一時期、EV証明書を発行する一部のCA事業者が、EV SSLの宣伝で「緑色になったら安全」などといいかげんな広告を打っていて、誤った理解が広まりかねないと心配されていたわけだが、「緑色になったら安全」という理解がなぜ駄目なのか、その理由の一つは、いわゆる「共用SSL」サービスにEV SSLが使われかねないという懸念だった。 そして、その実例が既に存在していたことに気付いた。図1は私が作ったWebページである。 アドレスバーは緑色になっているが、ここに入力されたデータは私宛にメールで送信*1されてくる。（このページは既に閉鎖している。） 悪意ある者がこうしたページを作成*2し、何らかの方法でこのページに人々を誘導*3すれば、フィッシングの被害が出るおそれがある。
高木浩光＠自宅の日記 - 事業者が今すぐできるフィッシング詐欺対策, 「フィッシング」に替わる適切な日本語は何か
■ 事業者が今すぐできるフィッシング詐欺対策 ここのところフィッシング(phishing)詐欺に注意を呼びかけるニュース記事や、メールマガジンが多くなってきた。Yahoo! BBのニュースレターでも、「フィッシング詐欺の対策を大紹介！」というサブジェクトで、「ヤフーBBマガジンクリップ ―― フィッシング詐欺に気をつけろ！」というコンテンツを流しているようだ。 国内で大流行する前にこうして消費者に注意を呼びかけることはよいことだ。だが、消費者の意識改革を促すよりも前に、事業者側で今すぐ可能な対策がある。それは昨年の6月14日の日記「HTMLメールマガジンのもうひとつの危険性」に書いていた、以下の話である。 偽メールの危険性を重視して、メールマガジンに電子署名するようにしてはどうだろうか。認証局方式の署名付きメールは今ひとつ普及していないが、これは、署名に必要な証明書が有料であるため、個人で
高木浩光＠自宅の日記 - フィッシング詐欺対策としてS/MIMEを導入する企業が急増……の兆しか
■ フィッシング詐欺対策としてS/MIMEを導入する企業が急増……の兆しか 武富士、フィッシング詐欺対策としてベリサインのPKIソリューションを採用 ―外部への電子署名付き電子メールでなりすましを防止―, 武富士 / 日本ベリサイン, 2004年11月29日 株式会社武富士（略）は、最近急増するフィッシング詐欺対策の一環として、 日本ベリサイン株式会社（略）の電子認証局構築サービス「ベリサインマネー ジドＰＫＩサービス」を採用し、年末を目処に同社社員の発信するすべての電 子メールに電子署名を実装することを発表いたします。（略） 武富士では、今後ますます顧客や外部との通信手段として重要化するであろう 電子メールについて、金融機関から発信する文書としての社会的責任について 検討してきました。（略） おお。 ちなみに、社員ひとりひとりにメールに署名させるシステムを構築するのは 大掛かり過ぎて、導
高木浩光＠自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する（閲覧者が望めば https:// でも閲覧できるようにする）のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 （8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。） それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
高木浩光＠自宅の日記 - EV SSL導入に伴い生じ得る特有の脆弱性
ANSER WEBというASPサービスでインターネットバンキングを提供している金融機関が、EV証明書を導入した理由は、「NTT DATA CORPORATION」という社会的信頼の高い企業による運営であるという表示によって、利用者に本物サイトであることの確認手段を提供したことにあるのだから、これらの金融機関は、利用者が「NTT DATA CORPORATION」という名称さえ見てくれればいいことを前提としている。 しかし、もし、図3のように、ドブログのようなサイトでまで緑色で「NTT DATA CORPORATION」と表示されるような世の中になってしまったら、どうなのだろうか。 まず、少なくとも、EV証明書導入サイトがやってはいけないことがある。 もし、ドブログのユーザコンテンツ（つまりブログ）のページが、https:// でも表示できるようになっていたらどうか。どこの馬の骨ともわからな
高木浩光＠自宅の日記 - Amazonは注文履歴の消去を拒否、アカウント閉鎖後もデータは残る
■ Amazonはやっぱり怖い そろそろ使うのをやめようと思う 今は朝6時。数時間前、寝ようとしたころに大騒ぎになっていた。 密かな趣味が全公開--Amazonのウィッシュリスト、改め「ほしい物リスト」に注意？, CNET Japan Staff BLOG, 2008年3月12日 これはひどいことになった。HATENA Co., LTD. では暗号解読の本をお求めのようだった。 幸い私は、ウィッシュリストを空にしていたので、何も見られることはなかったが、自分のAmazon登録メールアドレスを入れると、氏名と「茨城県」などの情報が表示された。（メールアドレスも非公開のものを使っているが、ワイルドカード指定もできたようなので、どうなっていたかわからない。もっとも、私は実名を隠していないが。） そもそも何年か前、この「ウィッシュリスト」なるサービスが始まったとき、やたらウイッシュリストへの登録が
高木浩光＠自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと
■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日本ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式
高木浩光＠自宅の日記 - 第六種オレオレ証明書が今後増加するおそれ, 訂正（15日）
■ 第六種オレオレ証明書が今後増加するおそれ リンク元を辿ったところ、東京証券取引所の「適時開示情報閲覧サービス」のサイトと、民主党のご意見送信フォームの送信先サーバ*1でオレオレ証明書が使われているという話を立て続けに見かけた。 無知な鯖管, 別館「S3日記」, 2007年12月9日 民主党のSSL証明書が不正な件, 思考と習作, 2007年12月10日 これらはどちらも、中間認証局から取得したサーバ証明書なのに、中間認証局の証明書をサーバに設置していないという、第六種オレオレ証明書の状態になっているようだ。 この場合、Internet Explorerアクセスするとオレオレ警告が出ないため、サーバ管理者が気づいていないのだと思われる。 IEで警告が出ないのは、IEには独自の機能が搭載されているからで、サーバ証明書に記載の「Authority Information Access」拡張フ
高木浩光＠自宅の日記 - オレオレ警告の無視が危険なこれだけの理由
警告を無視して先に進むと、その瞬間、HTTPのリクエストが cookie付きで送信される。 もし通信路上に盗聴者がいた場合*2、そのcookieは盗聴される。セッションIDが格納されているcookieが盗聴されれば、攻撃者によってそのセッションがハイジャックされてしまう。 「重要な情報さえ入れなければいいのだから」という認識で、オレオレ警告を無視して先を見に行ってしまうと、ログイン中のセッションをハイジャックされることになる。 今見ているのとは別のサイトへアクセスしようとしているのかもしれない さすがに、銀行を利用している最中でオレオレ警告が出たときに、興味本位で先に進む人はいないかもしれないが、銀行を利用した後、ログアウトしないで、別のサイトへ行ってしまった場合はどうだろうか。通常、銀行は数十分程度で強制ログアウトさせる作りになっているはずだが、その数十分の間に、通信路上の盗聴者により、
高木浩光＠自宅の日記 - 無線LANのMACアドレス制限の無意味さがあまり理解されていない
■ 無線LANのMACアドレス制限の無意味さがあまり理解されていない 職業マスメディアに代わって、ブログスタイルのニュースサイトが人気を博す時代になってきた。海外の話題を写真の転載で紹介する安直なニュースも人気だ。 このことろなぜか、無線LANのセキュリティ設定について書かれた記事を何度か見た。おそらく、ニンテンドーDSがWEPしかサポートしていないことが不安をもたらしている（そして実際に危険をもたらしている）ためだろうと思われる。 セキュリティの解説が増えてきたのはよいことなのだが、内容に誤りのあるものが少なくない。 実は危険な無線LAN, らばQ, 2007年10月21日 この記事には次の記述があるが、「接続されなければMACアドレスは盗まれない」という誤解があるようだ。 MACアドレスというのは、機器固有のIDのようなものです。たいていの無線LANアクセスポイントにはMACアドレスフ
高木浩光＠自宅の日記 - 緑シグナルが点灯しないのに誰も気にしていない？という不思議, 追記
■ 緑シグナルが点灯しないのに誰も気にしていない？という不思議 フィッシング対策ソフトの導入動向 最近、金融機関が「PhishWall」や「PhishCut」を導入したというニュースをよく見かけるなあと思っていたら、どうやら、金融庁の監督指針の今年の改定でフィッシング対策について明記されたことが関係しているらしい。 主要行等向けの総合的な監督指針（平成19年6月版）, 中小・地域金融機関向けの総合的な監督指針（平成19年8月版）, 金融庁 III-3-7 インターネットバンキング III-3-7-2 主な着眼点 (2) セキュリティの確保 ホームページのリンクに関し、利用者が取引相手を誤認するような構成になっていないか。また、フィッシング詐欺対策については、利用者がアクセスしているサイトが真正なサイトであることの証明を確認できるような措置を講じる等、業務に応じた適切な不正防止策を講じている
高木浩光＠自宅の日記 - 対策にならないフィッシング対策がまたもや無批判に宣伝されている, 追記（26日）
■ 対策にならないフィッシング対策がまたもや無批判に宣伝されている 「PCからオンライン取引、ケータイで認証」−ソフトバンクBBの新発想・認証サービス, Enterprise Watch, 2007年9月20日 「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。本当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。（略） 「PCを標的にしたハッキングやDoS攻撃を受ける可能性がゼロになる」（中島氏）。また、偽サイトとはシンクロしないため、フィッシング詐欺を100％防止することも可能だ。 ソフトバンクBB、携帯活用認証システムでWebサイトログイン対応に, ケータイWatch, 2007年9月20日 今回の新機能は、安全・簡便・低コストで、そう
高木浩光＠自宅の日記 - JPCERTも糞、ベリサインも糞、マイクロソフトは糞、トレンドマイクロも糞、フィッシング対策解説は糞ばかり
■ JPCERTも糞、ベリサインも糞、マイクロソフトは糞、トレンドマイクロも糞、フィッシング対策解説は糞ばかり 一昨年7月のWASフォーラムのイベントで話した以下の件。 セキュアなWebアプリ実現のために本来やるべきことは? - 高木浩光氏, MYCOM PCWEB, 2005年7月12日 誤った解説や必要以上に危機感を煽る報道に不満 （略）アドレスバーがきちんと表示されていてURLが確認できる状態になった上で、SSLの鍵マークが表示され、ブラウザがSSL証明書に関する警告画面を出さなければ、いちいち証明書を開かなくても安全性は確認できるのに、未だに「安全性を確認するには証明書を開く必要がある」といった誤った解説が(それもセキュリティに詳しいとされている記者の記事の中で)なされている」と指摘。その上で「キーワードジャーナリズムは、よりユーザにとって手間のかからない対策手法を紹介すべきだし、
高木浩光＠自宅の日記 - 銀行のフィッシング解説がなかなか正しくならない
■ 銀行のフィッシング解説がなかなか正しくならない みずほ銀行のトップページを訪れたところ、2月26日付けで「セキュリティガイド（4コマ漫画）を掲載いたしました」というお知らせが出ていた。見に行ってみると、「インターネットバンキング編」という解説があり、「 「フィッシング詐欺」に遭わないためには？」というページがあった。この出来が非常に悪く問題がある。 まず酷いのが、「電子メールが本物かどうかは、送信元アドレスで確認できます。」という完全に誤った解説だ。 「……@mizuhobank.co.jp」というメールアドレスを From: に書いてメールを送ることは誰にでも可能なわけだが、そんなことさえ知らないド素人に、こんな大事な解説の原稿を書かせる神経が理解できない。セキュリティ専門のコンサルに一読してもらうだけで防げるレベルのミスなのに、なぜそれをしないのか。 URLの確認方法として、「UR
高木浩光＠自宅の日記 - サイボウズが再び「闇改修」をしたので電話で抗議したが無駄骨だった
■ サイボウズが再び「闇改修」をしたので電話で抗議したが無駄骨だった 結果を先に言うと、サイボウズ社はセキュリティポリシーによって、（アカウントを持つユーザからしか攻撃され得ないなどの）危険な状況が少ない脆弱性については告知するが、第三者から攻撃され得る脆弱性については告知しない（更新履歴やFAQには書いておくが積極的に知らせることをしない）という方針で、今回も、過去もそうしてきたし、今後もそうしていくつもりなのだという。 複数のサイボウズ製品にセキュリティ・ホール，情報漏洩などの恐れ, 日経IT Pro, 2006年8月28日 （1）は，細工が施されたリクエストを送信されると，公開を意図していないファイル（公開用フォルダに置いていないファイル）を表示してしまうセキュリティ・ホール（略） （2）は，Office 6に関するセキュリティ・ホール（略）。細工が施されたリクエストを送信されると，
高木浩光＠自宅の日記 - サーバ証明書の期限切れ事故を防止するには？
■ サーバ証明書の期限切れ事故を防止するには？ JPNIC認証局なるものが実験運用されているようだ。利用対象者は「IPアドレス管理指定事業者」に限定されているため、物理的に配布されている「JPNIC認証局証明書の入手と確認の手順」に従うことになっているらしい。「誤った認証局証明書の組み込みは、Webサーバのなりすましの原因になります」との警告もされている。 それでもなお、fingerprintがWebにも掲示されている*1。ただし、https://serv.nic.ad.jp/capub/fingerprint.html という https のページに。そして、そのサーバのサーバ証明書は VeriSign発行のものになっている。そこまではよい。 だが、その証明書が7月20日で期限切れだ。 こうした事故はしばしば見かけるが、どうやって防止するのがよいのだろう？ 担当者が年がら年中、気にかける
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか
■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか 4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。 荒らし対策をするしないは運営者の自由 あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。 たとえば、IPA の脆弱性届出状
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
高木浩光＠自宅の日記 - ぜひ買いたいこの一冊（脆弱性コードレビュー練習用その1）, JPCERT/CCの判断力も蝕む サニタイズ脳の恐怖
■ ぜひ買いたいこの一冊（脆弱性コードレビュー練習用その1） ジュンク堂本店の「PHP」コーナーで一番目に付く位置に飾られていた本を読 んでみた。 改訂新版 基礎PHP, 山田祥寛監修、 WINGSプロジェクト（本田将輝、山葉寿和、斉藤崇、森山絵美、渕幸雄、青島裕、山田奈美）著, インプレス, 2004年10月1日初版発行 2005年12月11日第1版第5刷発行 帯の宣伝文句はこうだ。 PHP5で作るWebアプリケーション 待望の改訂版登場！ 最新機能まで踏み込んだ内容と、必要な環境を収録したCD-ROMで、着実に学ぶ 着実に……ですか。 最初の動くサンプルコードはこうなっている（p.72）。 <html> <head><title>hello_world.php</title></head> <body> <?php $var_str="Hello World"; print ($var
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
