au/KDDIの2011年秋冬モデル（現時点ではF001のみ）にてEZwebとPCサイトビューア（以下PCSV）のゲートウェイが統合されたことに伴い、かんたんログインを実装しているサイトに対して、F001のPCSVからJavaScriptを用いた「なりすまし」攻撃ができる状態でした。この問題をKDDIに通報したところ、直ちに対策が取られ、現在は安全な状態です。以下、詳しく報告します。 目次概要 経緯 何が問題か 経緯説明(1)基本的なチェックは対処済みだった 経緯説明(2)ハイフンをアンダースコアに変えるトリックは対策済み 経緯説明(3)海老原氏が発見したトリックとは 経緯説明(4)KDDIに連絡→翌日に対処 実証例 外部からJavaScriptを実行できる条件 影響を受けるサイトの条件 影響 対策 今回の問題は、端末あるいはau設備の脆弱性なのか まとめ 概要以前、「EZwebの2011
“特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 前回では、URLにセッションIDを埋め込むことの問題点を指摘した上で、今後はできるだけケータイでもCookieを使うことを提案しました。それを受けて今回は、前半で、ケータイWebでCookieを使う際の注意点について説明します。 そして後半では、連載の終わりに当たり、スマートフォンが普及しつつある状況下でのケータイWebの今後について説明します。 ケータイWebにおけるCookieは「取り扱い注意」 これまで説明したように、KDDIとソフトバンクのケータイでは従来からCookieが利用でき、NTTドコモの端末でも2009年夏モ
Webアプリのセキュリティを検討する「Webアプリケーションセキュリティフォーラム(WASForum)」が5月22日、認証と認可に関するイベントを開催した。その中で携帯電話の「かんたんログイン」のセキュリティに関して講演が行われた。 WASFは、もともとPCの一般的なインターネットのセキュリティを対象にしていたが、昨今のスマートフォンの流行などで携帯電話からも通常のインターネットが頻繁に利用されるようになったことから、今回のような考察が行われたという。 かんたんログインに関して講演をしたのは、HASHコンサルティングの徳丸浩氏と、産業技術総合研究所(産総研)の高木浩光氏。 パンドラの箱を開いたキャリア 携帯電話のWebサイト(携帯Web)で一般的に利用される「かんたんログイン」は、iモード(NTTドコモ)やEZweb(au)、Yahoo!ケータイ(ソフトバンクモバイル)で利用されているログ
ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 先日auからEZWebに関わる以下のようなアナウンスがなされた。 KDDI au: EZfactory EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。 これによる主な変更点は以下のとおりです。 ＜主な変更点＞ ・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。 ・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。 他にもCookie仕様の変更などがあるのだが注目すべきは、「EZブラウザとPCサイ
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
今回は、そのかんたんログインの問題点について説明します。 「契約者固有ID」を用いるかんたんログイン かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。 第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。 図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。 かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
HASHコンサルティング株式会社 公開日:2010年5月24日 概要 昨年11月24日づけアドバイザリにて、iモードブラウザ2.0のJavaScriptにより、携帯端末に割り当てられたID（以下、端末固有ID）を利用した認証機能（以下、かんたんログイン）に対する不正アクセスが可能となる場合があることを報告した。その後の調査により、同種の問題がYahoo!ケータイのブラウザ(通信事業者はソフトバンクモバイル)でも発生することを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者およびYahoo!ケータイ利用者には至急の対策を推奨する。 背景 携帯電話のかんたんログインとは、ケータイブラウザに用意された端末固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。Yahoo!ケータイでは、端末シリアル番号およびUIDの2種類の端末固有IDを提
■ まだまだ他でも破綻しているケータイID認証 前回の補足。以下は、私が気づいたことではなく、2009年夏に「かんたんログインが危うい」との話題で持ち切りだったときに、既に公に語られていたことである。 SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日 特にUserAgentからIMEI番号を正規表現などで抜き取ってそれだけを利用している場合は、この方法を使えば偽装可能。uidの方を使うようにした方がいいかも。 モバイル用GWのIPアドレスを気にしてた時代もあったなぁ, コメント欄#1, 匿名の臆病者, 2009年8月6日 透過プロクシという仕組みはご存じない? あ、ということは少なくともhttpsにx-jphone-uidが乗っていたら擬装の虞か。(端末はuidを吐かないので) しかし、携帯電話会社がこの
HASHコンサルティング株式会社 公開日:2009年11月24日 追記日:2010年1月21日 概要 iモードブラウザ2.0のJavaScriptとDNS Rebinding(DNSリバインディング)問題の組み合わせにより、iモードIDを利用した認証機能（以下かんたんログイン）に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景 携帯電話のかんたんログインとは、ケータイブラウザ（たとえばiモードブラウザ）に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送出される。現在、iモ
iモードブラウザ2.0のJavaScriptを調査･研究する過程で、iモード専用サイトのhtmlソースを閲覧する方法を発見しました。 今回発見した方法を用いれば、「ドコモ・ゲートウェイ以外からのアクセスを禁止している」、「サーチエンジンのクロールを禁止している」、「XSS脆弱性が存在しない」の三つの条件を満たしているiモード専用サイトでも、htmlソースを閲覧することができます。 しかし、htmlソースを閲覧するためには、そのiモード専用サイトが別の二つの条件を満たしている必要があります。 htmlソースが閲覧可能なiモード専用サイトの条件 デフォルトホストで運用されている。（ヴァーチャルホストではない） iモードブラウザ2.0のJavaScriptからのアクセスを禁止していない。 iモード専用サイトのhtmlソースの閲覧方法 iモードブラウザ2.0のJavaScriptで、htmlソース
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
大変ご無沙汰です。約1年半ぶりの更新です。 昨日、ブログを設置しているサーバでOSのアップデートに問題が発生したため、これを機に新サーバ・新OSに乗り換えることにしました。 現在のブログがマルチサイトのため、そのままでは新サーバの構築に苦戦すると予想されるため、他のブログの記事を統合しました。 統合内容は以下の通りです。 ・C-Production ・・・ メインサイトのため、他のブログを吸収して継続。 ・♪8thNote♪ ・・・ メインサイトに統合済みだったので、削除。 ・モバイル魂 ・・・ メインサイトに記事を引き継ぎ、並行稼働中。 ・無線のドキュメント ・・・ もともと閉鎖予定だったので、そのまま削除 外部SNSのアカウントについてはそのまま継続します。 今後ともよろしくお願いします。
「PHP x 携帯サイト デベロッパーズバイブル」に書かれている内容について、 セキュリティの点について徳丸浩様のサイトでご指摘を頂きました。 ■徳丸浩の日記 - 書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性 http://www.tokumaru.org/d/20081014.html ご指摘の通り「PHP x 携帯サイト デベロッパーズバイブル」の7章のかんたんログインの部分で、携帯電話ではセッションIDを用いる方法と、個体識別番号を使った方法を記載しておりますが、セキュリティに関する記述に不備がありました。 7章にかいてある「かんたんログイン」に関する方法は、リクエストヘッダーなどを書き換えることにより、第三者がなりすましてログインされてしまう可能性があります。 そのため「かんたんログイン」を実装する際は、携帯キャリアゲートウェイのIPアドレスから来るアクセスのみに限定
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する（閲覧者が望めば https:// でも閲覧できるようにする）のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 （8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。） それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
自転車とGREEについて自転車はGIANTがオススメGREEは2006年11月に携帯にシフト、携帯からのアクセスがぐんぐん増加 携帯の諸々Referer来ないかもしれない。auとSoftbankはおおむね来る。来ないなら来ないで統一されていれば良いものを……Cookieは、au来ます、Softbankは来ないかも。 Referer漏洩問題についてそもそも他サイトにリンクしないこと。ドコモ公式では必須端末不具合によって、何故かメールから叩いたURLに前のサイトのRefererが出ることが……セッション格納情報でチェックする? UA……Referer漏洩時点でばれている。端末固有情報?SIDを変えまくるという対策だと、戻ると死んだりするユーザがGREEにGREEのURLを貼ることは多い (URLにはセッション追跡情報がついている)。GREEではURLをパースしてがんばっている携帯ではHTMLソ
■ ケータイWebはそろそろ危険 これまでの背景と最近の状況変化 「安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基本手順は、（パスワードやカード番号などの）重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。 ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。 ジャンプ先URLを事前に確認したとしても、それが（任意サイトへの）リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。 そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
