タグ

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

  • 高木浩光@自宅の日記 - まだまだ他でも破綻しているケータイID認証

    ■ まだまだ他でも破綻しているケータイID認証 前回の補足。以下は、私が気づいたことではなく、2009年夏に「かんたんログインが危うい」との話題で持ち切りだったときに、既に公に語られていたことである。 SoftBank Mobileの携帯用GatewayPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日 特にUserAgentからIMEI番号を正規表現などで抜き取ってそれだけを利用している場合は、この方法を使えば偽装可能。uidの方を使うようにした方がいいかも。 モバイル用GWのIPアドレスを気にしてた時代もあったなぁ, コメント欄#1, 匿名の臆病者, 2009年8月6日 透過プロクシという仕組みはご存じない? あ、ということは少なくともhttpsにx-jphone-uidが乗っていたら擬装の虞か。(端末はuidを吐かないので) しかし、携帯電話会社がこの

  • 高木浩光@自宅の日記 - はてなのかんたんログインがオッピロゲだった件

    はてなのかんたんログインがオッピロゲだった件 かんたんログイン手法の脆弱性に対する責任は誰にあるのか, 徳丸浩の日記, 2010年2月12日 といった問題が指摘されているところだが、それ以前の話があるので書いておかねばならない。 昨年夏の話。 2009年8月初め、はてなブックマーク界隈では、ケータイサイトの「iモードID」などの契約者固有IDを用いた、いわゆる「かんたんログイン」機能の実装が危ういという話題で持ち切りだった。かんたんログイン実装のために必須の、IPアドレス制限*1を突破できてしまうのではないかという話だ。 実際に動いてすぐ使える「PHPによるかんたんログインサンプル」を作ってみました, ke-tai.org, 2009年7月31日 SoftBank Mobileの携帯用GatewayPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日 ソフ

  • 高木浩光@自宅の日記 - ドコモはXMLHttpRequestにiモードIDを載せるのを止めるべきだ

    ■ ドコモはXMLHttpRequestにiモードIDを載せるのを止めるべきだ (建設予定地) (27日追記)建設計画廃止。XMLHttpRequestだけ止めても効果がないことを理解したため。 (29日追記)何が言いたかったか、後日書く。

    clouder
    clouder 2009/11/26
    ん。
  • 高木浩光@自宅の日記 - こたえはきっとソースの中に 〜 ドコモのCAPTCHAモドキ

    そもそもこのサービスにとってCAPTCHAが何の意味をなすのか疑問*1だが、それはともかく、この部分のHTMLソースを見ると、画像のURLに答えが書かれている。(図2の「gifcat/call.php?SID=948545」) これでは何の意味もない。 これの目的がもし、他サイトからのリンクで検索させられる事態を防ぐためであるなら、画像なんか表示せず、直接INPUTフィールドに値を埋め込むようにしておけばいい話だ。*2 <input name="attestationkey" value="948545" type="hidden"> ちなみに、図2で示される画像のURLに直接アクセスしてみると、図3のように、リロードする毎に(同じ番号の)違う画像が現れる。何回か繰り返してみると、1つの数字あたり4種ほどの画像が用意されているだけだとわかる。 背景のノイズのようなものも、動的に生成されてい

    clouder
    clouder 2009/10/09
    ドコモだいじょうぶか!?
  • 高木浩光@自宅の日記 - やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合

    ■ やはり退化していた日のWeb開発者「ニコニコ動画×iPhone OS」の場合 一年前、「退化してゆく日のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。 iPhoneに契約者固有ID送信機能が搭載される日 (略)こうして退化してゆくケータイWebが、日のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。 (略)iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 (略)契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなけれ

  • 高木浩光@自宅の日記 - 米国ではストリートビュー撮影されない住宅街の道

    ■ 米国ではストリートビュー撮影されない住宅街の道 10月26日の日記「住宅ストリートビューの国際比較 アメリカ・フランス・日」で書き残したことを書いておく。 その日記の繰り返しになるが、私は、米国ではストリートビューはわりと受け入れられているのではないかと思っている。もちろん個別にプライバシーを侵害される事例もあって、どうやってそれが防がれるのかという問題はあるけれども、少なくとも住宅街の写真を撮られることへの嫌悪感に関しては、日での状況のようには深刻でないのではないかと思う。そのため、アメリカ人には日での嫌悪感が理解不能なのではないかと心配になる。このことは、早い時期から識者らによって指摘されていた。 Google の中の人への手紙 [日のストリートビューが気持ち悪いと思うワケ], higuchi.com blog, 2008年8月7日 日の都市部の生活道路は生活空間の一部で

  • 高木浩光@自宅の日記 - 楽天ad4Uの隠しリンクを露出させるユーザスタイルシート

    楽天ad4Uの隠しリンクを露出させるユーザスタイルシート 脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手に手を出した、掟破りの(自称「次世代」)行動ターゲティング広告「楽天ad4U」について、amachangの「IEのinnerHTMLやappendChildで要素が挿入された瞬間を取得する方法」を参考に、その隠しリンクを露出させるユーザスタイルシートを作ってみた。(Internet Explorer用。) #ad4u_list { display: expression(function() { if (!this.__mark) { this.__mark = true; // alert(this.innerHTML); var o = '<div style="overflow:scroll; border:dashed 4px red;">'; o = o + this

  • 高木浩光@自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに

    ■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP

  • 1