タグ

ブックマーク / takagi-hiromitsu.jp (5)

  • 高木浩光@自宅の日記 - かんたんログイン方式で漏洩事故が発生

    ■ かんたんログイン方式で漏洩事故が発生 ガラケーからiPhoneに乗り換えた人々が「ガラケーサイトが見れない!!」とご不満らしいという話は、聞いたことがあったし、そういう方々向けに「ガラケーサイトを閲覧できる」と謳うスマホ用の専用ソフトが提供されたというのも、どこかで見た記憶があった。 そんな10月9日の夜遅く、ある方から、「iPhone用のSBrowserというアプリで、クロネコヤマトのサイトを使ったら、知らない人の個人情報が出てきてびっくりした。どうしたらいいか」という相談が舞い込んできた。 早速、iTunes Appストアで「SBrowser」の商品説明ページを見に行ったところ、数々の雑言レビューが付いており(図1)、この種のアプリの需要とユーザ層が見えた。

  • 高木浩光@自宅の日記 - 今こそケータイID問題の解決に向けて

    ■ 今こそケータイID問題の解決に向けて 目次 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 Web開発技術者向けの講演でお話ししたこと 研究者向けの講演、消費者団体向けの講演でお話ししたこと 総務省がパブリックコメント募集中 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 6月初めのこと、ソフトバンクモバイルが「電波チェッカー」というiPhoneアプリを直々に開発して、iTunesストアで配布を始めたというニュースがあったのだが、それを伝えるITmediaの記事で、「取得された電波状況情報はiPhoneのUDIDとともにソフトバンクモバイルに報告される」と書かれているのが気になった。*1 「電波チェッカー」で検索して世間の反応を探ったところ、ソフトバンクモバイル社のCTO(最高技術責任者)の方が、Twitterで直々に市民と対話な

  • 高木浩光@自宅の日記 - 「VeriSignシール」という幻想

    ■ 「VeriSignシール」という幻想 オレオレ証明書ではないSSLサーバ証明書は、2つの独立した機能を果たしていると言える。1つ目は、SSLプロトコルによるサーバとクライアント間の暗号化通信のために不可欠な役割であり、2つ目は当該サイト運営者の実在証明の機能である。ただし、今日では、後者を含まない、前者だけのサーバ証明書もある。 後者の実在証明は、かつては認証局サービスを提供する各事業者がそれぞれの独自の基準で、サイト運営者の実在性を確認、認証していたが、それでは利用者にわかりにくいことから、認証の際の実在性確認の方法が標準化され、誕生したのがEV SSLであった。 その結果、VeriSignなど、古くから実在証明に力を入れていた認証局サービスでは、EVのものとEVでない実在証明付きサーバ証明書の2種類が存在することとなった。VeriSignでは、EV証明書の提供開始後も、EVでない実

  • 高木浩光@自宅の日記 - 共用SSLサーバの危険性が理解されていない

    ■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか?, さくらインターネット よくある質問(FAQ), 2010年2月10日更新(初出日不明) Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 (略) 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管

  • 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法

    ■ クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃(掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為)はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追

  • 1