タグ

セキュリティとmobileに関するshidhoのブックマーク (24)

  • SMSで送信元を偽装したメッセージを送る

    送信元表記が送信者IDのケース SMSのメッセージを受信した際に表示される送信元には、電話番号の代わりに任意の英数字も表記できる。この英数字の送信元表記を「送信者ID(Sender ID)」という。JC3の図では 通信事業者A が送信者IDに当たる。 なお送信者IDの利用可否は受信側の通信事業者の対応状況によって異なる。Twilioの販売パートナーであるKWCの説明によると、日国内ではNTT DOCOMOとSoftBankが送信者IDに対応し、KDDIは対応していないとのこと²。私はKDDIの回線を所有していないため、受信側がKDDIの電話番号を使用している場合の挙動は検証できていない。 まずはiOSの公式メッセージアプリに届いていたAmazonからのメッセージのスレッドで偽装を試みる。送信者IDは Amazon となっているため、TwilioでSMSを送信する際のFromの値に Ama

    SMSで送信元を偽装したメッセージを送る
  • 実は厄介、ケータイWebのセッション管理

    実は厄介、ケータイWebのセッション管理:再考・ケータイWebのセキュリティ(3)(1/3 ページ) “特殊だ”と形容されることの多い日の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます(編集部) 「Cookieを使えない端末」でセッションを管理する方法は? 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション(ケータイWeb)のセッション管理は、かんたんログインよりも対策が難しく、厄介な問

    実は厄介、ケータイWebのセッション管理
    shidho
    shidho 2011/05/27
    いまdocomoのcookie対応端末の普及率ってどのくらいだったっけ?1年くらい前だと5割行ってなかったような気がするんだけど。
  • 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://

  • 位置ゲーの位置詐称対策で検討すべき事

    OHTSUKA Ko-hei @kokogiko @niryuu 後者の前提で一般的な話をすると、結局ケータイでの位置取得はGET/POSTでの経緯度通知にすぎないので、ユーザが嘘情報を流し込むと詐称されてしまいます。なので、確実に自分達のリンクから来たと検証する手段か、GET/POSTの送付先を知られないための隠蔽手段が必要。 2010-06-09 23:49:30 OHTSUKA Ko-hei @kokogiko 前者の場合、Cookieに1回限りの使い捨てセッション埋め込んだり、Refererをチェックしたりで防げます。最近はCookieやRefererに対応したケータイが主流になってきたので、古い(と言っても意外と最近までですが)DoCoMoケータイを無視するならこれが一番簡単かと。 2010-06-09 23:52:27

    位置ゲーの位置詐称対策で検討すべき事
    shidho
    shidho 2010/06/16
    楽しそうだけど難しいね。
  • 高木浩光@自宅の日記 - ユニークIDがあれば認証ができるという幻想

    ■ ユニークIDがあれば認証ができるという幻想 2008年のNTTドコモによるiモードID送信開始以降、ケータイWebの世界に「かんたんログイン」なるエセ認証方式が急速に広がり、その実態は「はてなのかんたんログインがオッピロゲだった件」のように惨憺たるものになっている。こうした欠陥サイトはかなりあると考えられ、すべてを調べて廻ることはできないが、いくつかのメジャーどころのサイトについては、IPAの脆弱性届出窓口に通報して、対策を促す作業をやっている。 各サイトの「かんたんログイン」に欠陥があるかどうかは、実際に他人のIDでなりすましログインしてテストすることは許されない(不正アクセス禁止法違反になる)ので、自分用のアカウントを作成して(会員登録して)、自分のIDについてテストするのであるが、誰でも会員登録できるわけでないサイトがかなりあるようで、そういったサイトはどうしたらよいのか。以下は

    shidho
    shidho 2010/04/23
    認証はいらないけど、詐称されないユニークIDが欲しい場面はあるんだよなあ。
  • docomo IDについて サイト運営者様向け | NTTドコモ

    shidho
    shidho 2010/03/10
    穴は広がっていないけど、小さくなった訳ではないな。
  • docomo ID認証が怪しげすぎる件 | [ bROOM.LOG ! ]

    ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 NTTドコモがOpenIDを採用、PCサイトも“iモード認証”が可能に 「docomoがOpenIDに対応した」と話題になっているが、よくよく仕様書を見ると怪しげな点が多い。 ポイントはこの3つ。 ・RPに規制は無い(当たり前だけど)。つまり勝手サイト(勝手RP?)でも利用可能。これはケータイでも同じだけど ・iモードIDとUser-Agentを取得できる ・iモードID 取得はAXでもSREGでも無い独自仕様 つまり簡単に言うと、勝手サイトを立ててdocomo IDでログインできるようにして

    shidho
    shidho 2010/03/10
    id:nobeansの話が本当だとすると、iモードIDは払い出されないはずだから、ここに書いてあることは全部杞憂になるんだが、はてさて。/紐付け可能、ではあるけれど、DocomoIDだけでそれは無理なのか。
  • セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性

    iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 HASHコンサルティング株式会社 公開日:2009年11月24日 概要 iモードブラウザ2.0のJavaScriptDNS Rebinding問題の組み合わせにより、iモードIDを利用した認証機能(以下かんたんログイン)に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザ(たとえばiモードブラウザ)に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送

  • 高木浩光@自宅の日記 - Bluetoothで山手線の乗降パターンを追跡してみた , ユビキタス社会の歩き方(6) Bluetoothの「デバイスの公開」「検出可能にする」..

    Bluetoothで山手線の乗降パターンを追跡してみた この日記を書き始めてからもう6年になろうとしている。書き始めたきっかけは、RFIDタグのプライバシー問題が理解されないことに焦りを感じたからだった。当時の空気では、RFIDタグは5年後くらいに普及し、しだいにRFIDの埋め込まれた日用品で溢れかえるようになり、10年後くらいにプライバシー問題が顕在化すると目されていた。しかし、6年経った現在、私のにRFIDタグは埋め込まれていない。 当時の議論で描かれていたRFIDタグの問題は、無線LANやBluetoothにも共通することであり(MACアドレスがユニークIDとなる)、それらの方が先に普及するかもしれないという予感はあったが、現時点でも、無線LAN機器を持ち歩いている人はごく一部の人に限られている。しかし、Bluetoothはどうだろうか。これまでにも何度か、最近のBluetoo

  • http://twitter.com/HiromitsuTakagi/status/1074354271

    http://twitter.com/HiromitsuTakagi/status/1074354271
  • Q&A | お客様サポート | NTTドコモ

    Question.ワンクリックサイトから架空の請求を受けたのですが、ケータイのメールアドレスから個人情報が漏れることはありますか? Answer. ありません。 なお、URLやiモードサイト等をクリックすると、個人情報がわかるような表現で個体識別番号が表示されます。個体識別番号とは、製造番号や機種名などの携帯電話情報のことです。氏名、住所などの個人情報ではありませんのでご安心下さい。 また、携帯電話情報は送信される前に必ず確認画面が表示されますので、お客さまが承諾されないかぎり送信することはありません。 トラブルに巻き込まれないためにも、氏名、住所、メールアドレスなどの個人情報を安易に伝えないようご注意下さい。

    shidho
    shidho 2008/10/07
    微妙にずれてる、というかずれてきたんだろうなあ。
  • 高木浩光@自宅の日記 - ケータイWebはどうなるべきか

    ■ ケータイWebはどうなるべきか (未完成、あとで書く。) 技術的なセキュリティの話 先月27日の日記では、契約者固有IDによる「簡単ログイン」の危うさについて書いた。このログイン認証の実装方式は、携帯電話キャリアの「IPアドレス帯域」情報に基づいて、キャリアのゲートウェイからのアクセスのみ許すことによって、成り立ち得るものと考えられている(ケータイWeb開発者らには)ようだが、そもそも、その「IPアドレス帯域」なるものの安全な配布方式が用意されておらず、ケータイWeb運営者に対するDNSポイゾニング攻撃等によって、当該サイトに致命的な成り済まし被害が出かねない危険を孕んだものであることを書いた。 仮に、「IPアドレス帯域」の配布が安全に行われるようになったとしても、他にもリスクがある。通信路上に能動的盗聴者が現れたときに、致命的な成り済まし被害が出る。たとえば、6月3日の日記「通信路上

    shidho
    shidho 2008/08/17
    未稿の部分が難しいんだと思う。
  • 高木浩光@自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者

    馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する(閲覧者が望めば https:// でも閲覧できるようにする)のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 (8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。) それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに

    shidho
    shidho 2008/07/28
    IPアドレス範囲が信頼される状態で配信されて、そして。
  • 高木浩光@自宅の日記 - 日本のインターネットが終了する日

    ■ 日のインターネットが終了する日 (注記:この日記は、6月8日に書き始めたのをようやく書き上げたものである。そのため、考察は基的に6月8日の時点でのものであり、その後明らかになったことについては脚注でいくつか補足した。) 終わりの始まり 今年3月31日、NTTドコモのiモードが、契約者固有ID(個体識別番号)を全てのWebサーバに確認なしに自動通知するようになった*1。このことは施行1か月前にNTTドコモから予告されていた。 重要なお知らせ:『iモードID』の提供開始について, NTTドコモ, 2008年2月28日 ドコモは、お客様の利便性・満足の向上と、「iモード(R)」対応サイトの機能拡充を図るため、iモード上で閲覧可能な全てのサイトへの提供を可能としたユーザID『iモードID』(以下、iモードID)機能を提供いたします。 (略) ■お客様ご利用上の注意 ・iモードID通知設定は

    shidho
    shidho 2008/07/11
    mixiは通常のログインでもセッション維持に携帯固有IDを使っているけどね。
  • QRコードに隠したパスワードをケータイで取り出すソフト,NTT子会社が販売

    NTTアイティは2007年12月11日,QRコードに隠したパスワードを携帯電話で読み取るシステム「HaruPa」の販売を同月12日より開始すると発表した。ユーザーが複雑なパスワードを覚えることから開放するのが狙いだ。 HaruPaはQRコードを生成して,これを印刷するパソコン用の「HaruPa生成ソフト」と,QRコードを読み取るための携帯電話用の「HaruPa読み取りソフト」からなる。まず,生成ソフトで複雑なパスワードを自動的に生成してQRコードに変換,これを印刷する。携帯電話のカメラでQRコードを読み取れば,パスワードが表示される。 こうした仕組みだと,読み取りソフトが入っている携帯電話すべてから読み取れそうだが,あらかじめパソコンと携帯電話の双方に,対となる暗号鍵を登録しておくので,ユーザーが登録した携帯電話以外から読み取ることはできない。例えば,自分のパソコンの近くにQRコードを貼っ

    QRコードに隠したパスワードをケータイで取り出すソフト,NTT子会社が販売
    shidho
    shidho 2007/12/12
    生成したPC以外では使えないとなると、そのPCがダメになったときにはログイン出来ないのかな?わからん。
  • ここギコ!: 勝手サイトでは、位置情報詐称だけでなくユーザ詐称も大きな敵

    携帯の位置情報エンタテイメントサイトを作る際の強敵、位置情報詐称について以前取り上げましたが、勝手サイトで位置情報エンタメサイトを構築する場合、もう一つ強敵がいるように思います。 それは、DoCoMoでのセッションハイジャックによるユーザ詐称の問題です。 DoCoMoは、公式サイトだとアクセスする各ページ毎にユーザの登録者IDを返してくれるI/Fが存在するので、ユーザが詐称される危険性は存在しません。 問題は勝手サイトです。 勝手サイトでは、DoCoMoはユーザの登録者IDは通知してくれず、代わりに端末IDを返すI/Fが用意されています。 端末IDでも、機種変した場合他人になってしまうことや、端末を譲渡した場合他人が同一人物になってしまう点に注意すれば、基的には個人認証に利用可能です。 ですが、このI/Fが曲者で、このI/Fを通じてアクセスする毎にユーザに「端末番号を伝えてもよい

    shidho
    shidho 2007/09/20
    そうか、意図的にセッションを漏らす、という話もあり得るのか。
  • 高木浩光@自宅の日記 - 「ガラパゴス携帯のパラダイス鎖国」をWebの技術面から見る

    ■ 「ガラパゴス携帯のパラダイス鎖国」をWebの技術面から見る ワンクリック不当請求が問題となり携帯電話事業者各社が「お知らせ」を発表した2004年夏、8月29日の日記で総務省の「次世代移動体通信システム上のビジネスモデルに関する研究会」について少し触れた。実はもっと詳しく書くべき興味深い内容があったのだが、あまり言うのもいやらしい(せっかく解決に向けて動いて頂いているようなのに)という事情が当時はあったため、その後何もしていなかった。いまさらではあるが、これについて書き留めておく。 2000年に旧郵政省が「次世代移動体通信システム上のビジネスモデルに関する研究会」を開催していた*1。2001年に総務省情報通信政策局が報告書を公表している。 第1回 議事要旨, 郵政省, 2000年7月 第2回 議事要旨, 郵政省, 2000年9月 第3回 議事要旨, 郵政省, 2000年12月 第4回 議

    shidho
    shidho 2007/07/02
    長いけど読んでおかないといけないだろうなあ。今後のためにも。
  • 高木浩光@自宅の日記 - ケータイWebはそろそろ危険

    ■ ケータイWebはそろそろ危険 これまでの背景と最近の状況変化 「安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基手順は、(パスワードやカード番号などの)重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。 ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。 ジャンプ先URLを事前に確認したとしても、それが(任意サイトへの)リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。 そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセ

    shidho
    shidho 2007/06/25
    URL表示機能もないんだっけ?EZは。それ聞いて以来AUへMNPする意欲を失った自分がいる。
  • http://d.hatena.ne.jp/astronote/20070224

    shidho
    shidho 2007/02/26
    簡便と強固をどう両立するか、が見えない。
  • おさかなラボ - 携帯電話のIPアドレス制限神話

    珍しく間違った批判をしている高木先生@y-kawazの日記 但し、キャリア毎にIPアドレス制限をする限りにおいて この前提を満たすことが可能なのかどうかについて。 DoCoMo(i-mode) 情報はあくまでも目安としてご参照ください。iモードセンタ以外からIPアドレスでのアクセスがない事を保証するものではありません。 SoftBank 情報はあくまでも目安としてご参照ください。ゲートウェイ以外からIPアドレスでのアクセスがない事を保証するものではありません。 au(EZweb) 情報はEZサーバ以外のホストによる上記表のIPアドレスでのアクセスがないことを保証するものではありません。 まるでコピp…いや判で押したような記述だ。つまり、この情報を元にIPアドレス制限を行なっても携帯電話からのアクセスであると保証されるわけではないということだ。これではいわゆる野良

    shidho
    shidho 2007/02/26
    それは、IPアドレス偽装による攻撃の話じゃないの?