高木浩光＠自宅の日記 - 携帯電話販売店が本人同意を亡きものにする, 追記（21日）■ 携帯電話販売店が本人同意を亡きものにする 去年10月のこと。携帯電話をiPhone 5に機種変更するために、auショップを訪れたのだが、そこで、大方予想していた通りの事態が起きた。 店員は「接続テストをする」と言って、私の買ったばかりのiPhoneを、「ポポペポパポパ」と何も言わずに操作し、「できました」と言って、私に渡した。iPhoneの画面を見てみると、ホーム画面が出ていて、既に使える状態になっていた。
スマートフォンアプリケーションでSSLを使わないのは脆弱性か
このエントリでは、スマートフォンアプリケーションの通信暗号化の必要性について議論します。 はじめに 先日、スマートフォンアプリケーションのセキュリティに関するセミナーを聴講しました（2月8日追記。講演者からの依頼によりセミナーのサイトへのリンクをもうけました）。この際に、スマートフォンアプリケーションの脅威に対する共通認識がまだないという課題を改めて感じました。その課題を痛感できたという点で、セミナーは私にとっては有益でした。 このため、当ブログではスマートフォンアプリケーションの話題をあまり取り上げていませんでしたが、今後は、とりあげようと思います。まずは、スマートフォンアプリケーションでは暗号化を必須とするべきかという話題です。この話題は、前記セミナーでもとりあげられていました。 暗号化の目的は何か まず、暗号化の必要性を論じるためには、暗号化の目的を明確にする必要があります。前記セミ
secure.softbank.ne.jp廃止できません!? | 水無月ばけらのえび日記
公開: 2011年7月15日2時10分頃 これは驚きました……「モバイルバンキングは今でもsecure.softbank.ne.jp方式が主流 (d.hatena.ne.jp)」。 以下は、ログイン画面のURLがhttps://secure.softbank.ne.jp/～となっています。大手都市銀行は全てという感じです。 三井住友銀行三菱東京UFJ銀行みずほ銀行りそな銀行セブン銀行じぶん銀行住信SBIネット銀行楽天銀行新生銀行secure.softbank.ne.jpはホワイトリスト方式で残されるということでしたが、上記モバイルバンキングは、そのホワイトリストの対象なのでしょう。 なんということでしょう。 7月からは、secure.softbank.ne.jpで表示されるのは公式サイトのみ (かつ、ソフトバンクに申請したサイトのみ) になりましたから、公式サイトと無関係の者が罠コンテンツ
みずほダイレクトの謎 - ockeghem's blog
ソフトバンク携帯電話のSSL方式変更に伴い、みずほ銀行のモバイルバンキングが一部使えなくなっていましたが、昨日復旧したようです。 7月3日時点では、みずほダイレクトのトップに以下のように表示されていました。URLは魚拓のものです。 現在、ソフトバンクの携帯電話からアクセスいただいた、みずほダイレクト（モバイルバンキング）の［ネット決済振込サービス］および［Pay-easy（ペイジー）税金・料金払込みサービス］において、一部のお取引がご利用いただけません。「ご利用の端末のユーザーIDを「ON」に設定し、再度アクセスしてください。」と表示された場合には、パソコンなどでご利用ください。 お客さまには大変ご迷惑をおかけしておりますことをお詫び申しあげます。 （原因につきましては現在調査中です。） http://megalodon.jp/2011-0703-0032-51/www.mizuhoban
secure.softbank.ne.jp廃止の舞台裏 | 水無月ばけらのえび日記
公開: 2011年7月11日2時10分頃 secure.softbank.ne.jpが廃止されたことに伴い、なぜ廃止しなければならなかったのか、その背景についての解説が相次いで公開されています。 secure.softbank.ne.jp ヤバイの話 (subtech.g.hatena.ne.jp)SoftBankガラケーの致命的な脆弱性がようやく解消 (takagi-hiromitsu.jp)ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る (blog.tokumaru.org)secure.softbank.ne.jp ヤバイの話+ (subtech.g.hatena.ne.jp)先月まで、ソフトバンクのケータイサイトで https://example.com/ へのリンクを辿ろうとすると、以下のような動作になっていました。 ソフトバンクのケータイでサイトにアクセスすると、ゲートウ
私はいかにしてソフトバンク端末60機種のJavaScriptを検証したか - ockeghem's blog
昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方（この方）から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました（参考のやりとり）。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip
EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点 - ockeghem's blog
au/KDDIの技術情報サイトEZfactoryには、2011年秋冬モデル以降にEZwebの仕様変更がある旨表示されています。セキュリティ上の問題の可能性もあるため以下に報告します。 EZfactoryトップページでの告知内容 EZfactoryトップページには、2011年秋冬モデルでの変更を以下のように要約しています。 ※お知らせ※ EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。 これによる主な変更点は以下のとおりです。 ＜主な変更点＞ ・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。 ・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。 今後EZブラウザ向けコンテンツを作成する場合は、XHTML Basicを推奨します。 http://www.au.kddi.com/ezfactory
w3cもケータイ認証には困惑している件 | [ bROOM.LOG ! ]
ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 以前Twitterでもツイートしてたんだけど一部誤解があったのでこちらでまとめてみる。 Global Authoring Practices for the Mobile Web (Luca Passani) http://www.passani.it/gap/ 上記をもって「w3cが個体識別番号に駄目出し」としていたんだけど、多少事情が違った。 実は上記には元になる対象文書がある。それがw3cのベストプラクティスだ。 Mobile Web Best Practices 1.0 http://
高木浩光＠自宅の日記 - 今こそケータイID問題の解決に向けて
■ 今こそケータイID問題の解決に向けて 目次 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 Web開発技術者向けの講演でお話ししたこと 研究者向けの講演、消費者団体向けの講演でお話ししたこと 総務省がパブリックコメント募集中 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 6月初めのこと、ソフトバンクモバイルが「電波チェッカー」というiPhoneアプリを直々に開発して、iTunesストアで配布を始めたというニュースがあったのだが、それを伝えるITmediaの記事で、「取得された電波状況情報はiPhoneのUDIDとともにソフトバンクモバイルに報告される」と書かれているのが気になった。*1 「電波チェッカー」で検索して世間の反応を探ったところ、ソフトバンクモバイル社のCTO（最高技術責任者）の方が、Twitterで直々に市民と対話な
SSLプロキシの挙動についてソフトバンクモバイル 宮川CTOに何とかしてと頼んだらすぐに何とかなった話
ほんの1時間前まで全貌を把握してなかったので気が引けたけど、これもちゃんとまとめないと不公平と感じたのでまとめました。 全体把握できていないと思うので足りない部分ありましたら補足をお願いします。 参考: OpenPNE 3.5.3 での「かんたんログイン」の端末固有IDからの（部分的）脱却で困った点 | co3k.org http://bit.ly/au5BfJ 続きを読む
高木浩光＠自宅の日記 - KDDIの固体バカが言う「EZ番号はプライバシーに関する情報ではない」
■ KDDIの固体バカが言う「EZ番号はプライバシーに関する情報ではない」 これまで、契約者固有ID（サブスクライバID）について、それ単体では「個人情報」（日本の個人情報保護法が言う）に該当しないという法解釈は存在した。それは、個人情報保護法がそういう法律だから（プライバシー保護の法律じゃないから）そういうものだという話*1だった。それでも、4月3日の日記にも書いたように、ウィルコムからは、「CPに対しても個人情報保護法に従った慎重な取扱いを求めています」という回答を得ていた。 ところが、auのKDDIが、以下のQ&Aを掲載していることに気づいた。 EZ番号（固体識別番号）を変更したい。, auお客様サポート よくあるご質問 「EZ番号」（固体識別番号）はau電話ごとに割り振られており、変更することができません。 ■EZ番号はお客さまがURLにアクセスした際にサイト提供元のサーバに通知さ
SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ - hideden.hatenablog.com
2009-08-02 15:10:00 iPhone使わない方法を追記 iPhoneを色々いじってる過程でやってみたら出来たのでメモ。さほど悪い事は出来ないと思うけど、色々自己責任で。 iPhoneとSBMガラケーでは全く別のネットワークを使用しているため、通常iPhoneからは公式サイトやIPでアクセス制限をかけてる勝手サイトは見る事が出来ない。特に見る必要も無いのだが、実験としてやってみた。 iPhoneは通常 "smile.world" というAPNに接続している。一方、ガラケーはググって見たところ "mailwebservice.softbank.ne.jp" というAPNに接続しているらしい。っと言うことは、iPhoneの接続先をこれに変えてしまえばiPhoneもSBMガラケー側のネットワークに入れる・・・はず。 用意するモノ 香港版 or SIMUnlock済みの iPhone
高木浩光＠自宅の日記 - ユニークIDがあれば認証ができるという幻想
■ ユニークIDがあれば認証ができるという幻想 2008年のNTTドコモによるiモードID送信開始以降、ケータイWebの世界に「かんたんログイン」なるエセ認証方式が急速に広がり、その実態は「はてなのかんたんログインがオッピロゲだった件」のように惨憺たるものになっている。こうした欠陥サイトはかなりあると考えられ、すべてを調べて廻ることはできないが、いくつかのメジャーどころのサイトについては、IPAの脆弱性届出窓口に通報して、対策を促す作業をやっている。 各サイトの「かんたんログイン」に欠陥があるかどうかは、実際に他人のIDでなりすましログインしてテストすることは許されない（不正アクセス禁止法違反になる）ので、自分用のアカウントを作成して（会員登録して）、自分のIDについてテストするのであるが、誰でも会員登録できるわけでないサイトがかなりあるようで、そういったサイトはどうしたらよいのか。以下は
高木浩光＠自宅の日記 - はてなのかんたんログインがオッピロゲだった件
■ はてなのかんたんログインがオッピロゲだった件 かんたんログイン手法の脆弱性に対する責任は誰にあるのか, 徳丸浩の日記, 2010年2月12日 といった問題が指摘されているところだが、それ以前の話があるので書いておかねばならない。 昨年夏の話。 2009年8月初め、はてなブックマーク界隈では、ケータイサイトの「iモードID」などの契約者固有IDを用いた、いわゆる「かんたんログイン」機能の実装が危ういという話題で持ち切りだった。かんたんログイン実装のために必須の、IPアドレス制限*1を突破できてしまうのではないかという話だ。 実際に動いてすぐ使える「PHPによるかんたんログインサンプル」を作ってみました, ke-tai.org, 2009年7月31日 SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日 ソフ
セッション管理無しのケータイサイト | 水無月ばけらのえび日記
公開: 2009年7月15日18時50分頃 「携帯電話向けWebアプリのセッション管理はどうなっているか (d.hatena.ne.jp)」。 PHP×携帯サイト 実践アプリケーション集 (www.amazon.co.jp)のアプリケーションが、ことごとく個体識別番号に依存した作りになっているらしいというお話。携帯電話向けサイトでは、Cookie非対応端末のために、セッションIDがURLに含まれるという作りが一般的です。が、この本ではそういうことはしないで、アクセスごとに個体識別番号を見る設計になっているのだそうで。 個体識別番号に依存した認証については、高木さんの「無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者 (takagi-hiromitsu.jp)」でも問題が指摘されていますが、ここではさらに「標準的なセキュリテイ対策手法が使用できない」ことが指摘
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iPhoneアプリ「電波チェッカー」がUDID偽装可能だったことが発覚してからのまとめ