【技術ネタ】 携帯で端末ID詐称は可能かもしれない話

高木さんの「素朴な」疑問に対して、果たして携帯Webアプリでセッションは安全かの議論が続いている。

携帯電話向けWebアプリの脆弱性事情はどうなっているのか
珍しく間違った批判をしている高木先生
携帯電話からセッションIDの漏洩を防ぐ

Cookieが使えない機種も多いのでGETパラメータにセッションIDを埋め込む手法への疑問と、端末IDの信頼性の二つが論点かと思うのだけど、ここでは後者をちょっと考えたい。
いわゆる端末IDについてはこちらが詳しいのだけど、議論を整理すると、端末ID(もしくはユーザID)を安全足らしめるには次の要素が必要と考えられている。

1. SRC IPを制限して、各キャリアの携帯網からのアクセスのみ許可する。
2. 携帯端末の端末IDやUser-Agent環境変数はPCと違って変更不能

ところがこの1, 2は突破可能だ。
うちのようなサイトを巡回している人なら自明の理だと思うんだけど、Windows Mobileなどを搭載したスマートフォンなら、少なくともUser-AgentはNetFrontなどのブラウザ機能で簡単に変更できてしまう。
そしてまた、設定をごにょごにょいじることで、携帯網にもアクセス可能だ。例えば僕のHTC Universalという海外で発売されたSIMフリーのスマートフォンでSoftbankのSIMを挿してYahoo!ケータイが使えます。この場合、サーバからは一般の携帯からのアクセスとの違いはかなり気を付けていないと分からないはずだ。
例を示そう。

まず以下は普通にSoftbank携帯からWebサーバにアクセスして、CGIで環境変数を見たところ。
マスクしてますが、User-Agentとx-jphone-uidが取得されたのが分かる。User-AgentのSN...ってのが端末シリアル番号ですね。




次にスマートフォンからUser-Agentを偽装してリクエストしてみる。




User-Agentの端末シリアル番号の下四桁が0000に偽装されているのが分かると思う。
なおx-jphone-uidはNetFrontでは任意のヘッダーは追加できないので、そのままです。つまりx-jphone-uidは基地局やゲートウェイが追加する変数ということになる。

ここで、更に端末IDを安全足らしめる条件を追加してみよう。

3. 基地局またはゲートウェイが端末を認識してコントロールするIDを挿入すること

今回環境が揃わなかったのでテストできませんでしたが、Docomoで言えばuid, Softbankならx-jphone-uid、auならX-Up-Subnoということになると思うのだけど、仮にこれらが任意に端末から追加されていたら何も基地局やゲートウェイが書き換えたり削除しない仕様だとすると、端末IDは偽装放題ということになります。
つまりいわゆるユーザIDが最後の砦となっていると思うのだけど、果たして、このへんの実態はどうなんだろうか。
多分、簡単なWMアプリを作って確認すればすぐ分かると思うけど。
(あ、auだけは安全かも。独自仕様過ぎて携帯網につながるスマートフォンがまだないので。でも、近々出すって言ってたっけな)

また、Webアプリの仕様の問題もある。
実際User-Agentしか見ていなくて、スマートフォンから簡単にログイン可能になっているサービスを確認しています。

これを脆弱性と呼ぶかどうか。
IPAとかに連絡してもいいかも知れないけど、僕自身は以前に通報したらそんなの脆弱性とは呼ばないとか叩かれたりもしたし、実は普段の携帯とスマートフォンで便利に使い分けられてたりするので、今回はパスしますが。

# 過去にはこの仕様でもOKだったんだけど、時代が変わって事情が変わってきたと言うところだろうか。

【技術ネタ】 Yahoo!ケータイ経由だとPCサイトのブラウズを携帯向けに最適化できる

今日から始まったYahoo!ケータイを少し触っていたのですが、Yahoo!ケータイから検索してPCサイトを見ると、どうやらjigブラウザWebで最適化してくれることに気付きました。
検索結果のうち「PCサイト」のところのリンクからサイトに飛ぶとjigブラウザWeb用サーバらしいYahooのサーバ経由になり、PCサイトでも携帯向けに最適化してくれます。

いつからこうなっていたのか知らないのですが、これはいいですね。
本来なら月300円ほどかかるものが、Yahoo経由で検索して飛ぶだけでタダで使えてしまいます。
「Yahooサイトならコンテンツが無料になり、ドコモやAUのビジネスモデルを潰す」のが新生SoftBankの戦略だそうですが、SoftBank公式サイトやYahoo(のコンテンツサイト)さえ使わなくとも、既に普通のPCサイトを手軽にしかもタダで携帯からブラウズ可能になっているとは。

いわゆるフルブラウザではないですが、月課金とか無しでニュースサイトを色々見てみたい際には便利に使えそうです。

例えばGoogle Newsはテキスト版でもかなりサイズが大きくて携帯からはブラウズできませんでしたが、次のような手順で見ることができるようになります。
1. Yahoo!ケータイトップから「google news」とか検索してみる。
2. ケータイ検索結果に引き続いて、PC検索結果が表示されるので「Google ニュース 日本語版」を探してクリック
3. 最適化されたGoogleニュース日本語版サイトが表示される
これだけです。
後はブックマークしておくなりすれば即座にブラウズ可能になります。

因みにこの場合のURLは次のようになっています。

http://pctransnnn.mobile.tnz.yahoo.co.jp/fweb/xxx...xxxx/9b?_jig_=http%3A%2F%2Fnews.google.com%2Fnews%3Fned%3Dtjp%26rec%3D0

ここでnnnとxxx...xxxxはランダムに付帯されるようなので、ずっと有効かどうかは不明です。
またパラメータを変更してやれば他のサイトもダイレクトに利用できそうですね。

特に公式なアナウンスされていないかも知れないので、ご利用は自己責任でどうぞ。

【技術ネタ】 Google Calendar API は混乱中？

どうも昨日か今日当たりでGoogle Calendar APIの実装がUpdateされ混乱しているような気がします。
元々終日の予定の場合何故か開始/終了日時の年に3994年など有り得ない数値を返すバグが登場直後からずっとあったんですが、突然直ってしまいました。

反面、終日一日を示すXML表記は「Developer's Guide」のCommon Elementsによれば、

<gd:when startTime="2005-09-25"/>

などとするんですが、何故か

<gd:when startTime="2006-09-25" endTime="2006-09-26">

とかなってたり。
これだと二日間にしかならないはずなんだけど・・。完全に仕様違反です。

因みに、やはり終日の予定では指定した日付より一日前の日付で登録されてしまうバグがあるんだけど、これはまだ直っていない。

ちょっとしか見てないけど、アラアラですねぇ。他にもあるかも。
ここしばらくはちょっと要注意だなぁ。早く安定しますように。

【技術ネタ】 ソフトウェアでのロードバランシングは本当に使えるか

最近ソフトウェアによるロードバランジングネタがちょっとアツい。
元々は

チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか

って記事が出て(これはこれで目から鱗だったのだけど)

そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか

という突っ込みを経て

ロードバランサの運用.DSRって知ってますか?
DNSラウンドロビンとmod_proxy_balancerによるWebサイトの負荷分散（案）

という発展を見せてます。
リアルの仕事でもロードバランサーは頻繁に使うのだけどこれまではBIG-IPなどのハードウェアで対処してます。
つまり「リッチ・エンジニアリング」だったのだけど、ソフトウェアで手軽に担保できるのならそれに越したことはない！
実はずっと以前にソフトで対応できないか調べて挫折した経緯があり、果たしてこの2006年現在で、ソフトウェアによるロードバランシングが使えるレベルなのかどうか、ちょっと考えてみる。
因みに何一つ実際には試してませんので、そのつもりで。

続きを読む

【技術ネタ】 POP version4?

GIGAZINEから。
POP version4だとか。

Post Office Protocol Version 4

Internet Draftになっている訳でもなくどういう経緯で考えられたのかちょっと分かりませんが、仕様自体はなかなか面白いです。
幾つかサマリーすると、

●サーバーサイド・フォルダ

Inbox以外のフォルダを作成したり管理することが可能。Sent BoxとかTrashとか。

●メッセージID

UIDLを使用する

●フラグ

メッセージにフラグを付加可能

●メッセージ・パートの表示

MIME構造を表示可能に。またパート単位での受信対応。

●容量管理

フォルダの最大サイズを指定可能

●永続接続のサポート

繋ぎっぱなしにできるのでレスポンスが改善される(はず)

など。
IMAP4から仕様を吸収しているのが分かります。
言うなれば、IMAP4との折衷案といったところでしょうか。また一方で仕様が複雑になりそうなタグだとかサーバー・プッシュなどは排除されているのは面白いですね。

IMAP4は結局POP3ほどの広まりを見せませんでしたが、これは一言で言って、サーバーサイドで全て管理可能にしようとすると管理側の負荷コストが高くついてしまう事が原因だったでしょう。
メールは基本的にはクライアント側へダウンロードしてもらうことにして、POP3では対応しないフォルダ管理とか「美味しいところだけ」実装する、というのは意外に見極めとしてはいいかも知れません。


本当に使えるのなら使ってみたい気にはなりましたが、でも今更は広まらないんだろうなぁ。

【技術ネタ】 Google Calendar API C#ライブラリが1.0.2にバージョンアップ

いつの間にか、1.0.1 -> 1.0.2になっていました。
リリースノートに以下のような記載が。

added an AllDay flag to the When class to allow parsing and persting of all day events

以前「終日」予定が指定できないと書きましたが、これに対応したみたいですね。さすがに終日予定が指定できないのはまずいかったでしょうしね。
具体的には、WhenクラスにAllDay属性が追加されました。
QueryでAtomEntryを読み込めば終日の場合はこのAllDayがtrueになっているし、AllDayをtrueにしてInsert/Updateすれば終日予定になる、という訳ですね。

ol2gcではこのC#ライブラリを独自に変更して終日指定を可能にしていたのですが、1.0.2のコードを読むとほとんど同じでした。実はAllDayという属性名も同じです。
人間考えつくことは、大して変わらないもんだなぁ。

後は、C#のDeveloper's Guideがもう少し詳細and分かり易くなってくれれば・・。

【技術ネタ】 Google Calendar API のTips(覚え書き)

Google Calendar APIをC#で弄っていたんだけど、まだまだ日本語情報は少ないですね。
「Developer's Guide」も網羅されているようで、細かいところがよく分からない。特にC#とかのライブラリを使った場合の動作とか。(英文をいまいち理解していないという話はある・・)
で、特にUpdate/Deleteあたりではまったので、自分用も含めて覚え書き。
基本的にC#前提ですが、要領は他の言語でも同じかと。

続きを読む

【技術ネタ】 Google Web Toolkit が凄すぎる

Googleから「Ajaxアプリケーションを簡易に開発するツールキット」という謳い文句でGoogle Web Toolkit ベータ版 (GWT) がリリースされました。

何となく、Yahooが同様に出したライブラリの延長線上のようなものだと思っていて気楽に眺めてみたのですが、とんでもない。ぶっとびました。
GWT は言うなればJavaのSwing/AWTや一部のクラスを完全に置換する、一種のプラットフォームとして開発されています。
そこまでしてAjaxへコミットしたGoogleにやはり脱帽です。



続きを読む

【技術ネタ】 Google Calendar Data API

HepCat Dev and Testさん経由。
Google CalenderのWeb APIが公開(何故だか重めです)されたそうです。
Google Data APIs Protocol(GData)というGoogleでの汎用的なAPIが定義されていて、そこから派生されているんだそうです。
プロトコル自体はThe Atom Publishing Protocol＋OpenSearchになっていると。ふむふむ。興味深いですね。やっぱり今日びiCalでもないしって思ったんでしょうね。

続きを読む

【技術ネタ】 BlogコンテンツをFirefoxにも対応してみる

実はサイドバーのアクセス・トップ10とか記事のはてブ言及数表示にFirefoxだとエラーになっていることに気付きました。
ぶっちゃけFirefoxはどうでもいいやなどと思ったものの、とりあえずせこせこと直してみたので覚え書き。
ほとんどOperaとかIE6での動作しか気にしていなかったので、意外に新鮮かも。

細かなことで取り留めないんですが、IEとかOperaに慣れていた人が陥りやすいクロスプラットフォームのためのTipsになったので、一応何かの役に立つかもなので載せておきます。

続きを読む

【技術ネタ】 楽天のRSSがひどすぎる件

楽天市場が配信する売れ筋ランキングのRSSを初めて見たのですが、あまりにひどくて唖然。
どうも昨年の8月頃から配信を始めたようですが、まともな体を成していないと思う。
例えばこちらがパソコン・家電・AV用のRSSなんですが、

http://event.rakuten.co.jp/ranking/rss/pc.xml

• 売り文句が最前面に出たタイトルや内容はまだいいとして、descriptionに説明を全部ぶち込もうとしているのは何だろうか。しかもCDATAで囲むのは不自然？では？


• 何故にRSS2.0なのだろうか。特にenclosureで何かを読ませたい訳でも無さそう。しかもdescriptionにイメージとリンクを入れるぐらいなら、せめてcontentモジュールを拡張するか、いっそのことRSS1.0などでいいのでは。そもそもRSS2.0を使っているポリシーがよく分からない。


• item要素にpubDateが無い。channel要素にlastBuildDateはあるのだけど。よって、お馬鹿なRSSリーダーではクロールの度に同じitemを繰り返し読まされることに。
  (infoseek RSSリーダーとかで読んでみましょう(^^;)


• link要素に何故RedirectorへのURLを指定するのか。そんなにクリック数をカウントしたい？？直リンクじゃ駄目な訳は何だろうか。


• どこにRSSへのリンクが集まっているのか、全然分からなかった。結局infoseek RSSリーダーのプリ登録されたURLから探したけど、総合ランキングは未だに分からず・・。


• パソコンだけとか家電だけとかのRSSが無い(または見つからず)。範囲広すぎ。Webサイト自体はもっとカテゴリーが細分化できてるのに。加湿器とメモリスティックが同じランキングに登場していてそこから何を読めというのか。


• このパソコン・家電・AV用RSSなどは最終更新日が2月22日。つまり一ヶ月以上更新無し。大カテゴリのRSSは大体それぐらい。運営側が存在を忘れているんじゃないか？？


• Auto Discoveryぐらいランキングページで対応しておいたらどうだろうか。

こんなところですか。
RSSは、ただ提供したからいいというものでもないと思うので。もったいないですね。
ぜひどこかのニュースサイトで楽天の担当者に「楽天におけるWeb2.0対応」とか何とかのネタでインタビューとかして欲しい(そう言えば楽天に限ってそういうの見たことないなぁ)。何を答えるのか、大いに興味がある。

【技術ネタ】 RSS配信をカスタマイズする意味

近頃考えていたことに関連して、ちょっと面白い記事を見つけました。

RSS フィードの SEO 対策 - 9つのポイント(?) - My RSS 管理人 ブログ

RSSフィードの SEO 対策(?)

1. 全文を配信する
2. 20以上のアイテムを配信する
3. カテゴリ別など複数種類のフィードを配信する
4. アイテムタイトルはキーワード中心にする
5. アイテムタイトルにブランド名を入れる
6. 最も重要なキーワードをサイトタイトルに入れる
7. わかりやすいサイト要約をつける(サイトのdescriptionタグ内)
8. URLにトラッキングコードを入れない(例: &source=rss)
9. Podcasting などの付帯情報(enclosure)を入れると被参照範囲が広がる

記事の趣旨としてはSEO対策のためとなっていますが、一方でこれは如何にブログエントリーの流通性を高めるか、という指摘でもあります。
指針で惹かれるのは、やはり全文配信の是非についてでしょう。
但し、多くのブログではそもそも全文配信を選ぶことさえ出来ない場合が多いです。
さすがにMT辺りではカスタマイズ可能ですが、多くのBlog事業者の提供するASP型Blogではほとんどの場合記事概要や本文(追記除く)がデフォルトで、全ての記事を配信させることは意外にも出来ません。
これほどBlogが一般化している中でこれは意外な盲点のようにも思います。

続きを読む

【技術ネタ】 アクセス解析にもRSSが付けばいいのに

ちょっとしたアイデアです。
ふと思いついたのが、Blogのサイドバーに「アクセス数トップ10」を付けたいな、ということ。
Seesaaではそんなサイドバーは用意していないので自分で取り付けることになるが、問題なのはどうやってアクセス数トップ10を取得するか。
一番簡単なのは、普段使ってるアクセス解析サービスからトップ10を取得することなのだけど、意外にそんなことが出来るサービスが無い。
例えばSHINOBI.JPにせよCGIBoyにしても、Webブラウザから解析結果を見るのは何ら問題ないのだけれど、結果を色々いじくってみようとすると、とたんに何もできなくなってしまう。
Webブラウザからの解析に特化してしまっていて、応用性が無いのだ。
場合によってはFlash画面だったりして。ブラウザで使う分には便利なのだけど。

続きを読む

【技術ネタ】 SkypeへSkypeOut用コンタクトをインポートする場合のゆゆしき問題

話としては簡単で、せっかくSkypeOutを使うのであれば携帯のアドレス帳を何らかの方法でエクスポートしてSkypeのコンタクトリストへやはり何らかの方法でインポートし、普段使い慣れたアドレス帳の内容でSkypeOutを掛けたい、と思った訳です。つまりは電話番号をコンタクトに取り込みたい、というニーズです。
SkypeOutを利用するに当たり、誰もが望むあたりではないかと思います。
しかしまさかそこに、この手のことではありがちな、簡単に人を萎えさせる深い問題が潜んでいようとは・・。

続きを読む

【技術ネタ】 SkypeIn通話を携帯に転送する

先日、「Skypeで不在だったら指定した携帯に転送するとか、固定・携帯・IP電話の垣根を取り払うようなサービスを目指して欲しい」てなことを言ったんですが、そんな機能ぐらいは付いていたんですね。



続きを読む

【技術ネタ】 SkypeInを買ってみた

Skypeで日本向けSkypeIn(ベータ)が始まったということなので、さっそく買ってみました。

これはいわゆる050番号で、従来のSkypeのようにユーザー名ではなく、050-XXXX-XXXXという電話番号が割り当てられて固定電話や携帯からもかけられるサービスです。



続きを読む

【技術ネタ】 Google Toolbar 4.0 ベータ

Google Toolbar 4.0ベータが公開。
今回Send ToからSMS送信があるようなので試してみましたが、やっぱりというか米国内向けなんですね。残念。
PCからSMS送信可能なサービスを探してるんですが、いいところがないなぁ。

他の機能としてはGoogleアカウントへのログイン対応やブックマーク機能とかもいい感じ。
アカウントとの連携機能がいろいろ進むと面白いかも知れませんね。

【技術ネタ】 野良電波探訪

今日都バスに乗る機会があり、Qtek9000を持っていたので、試しにWifiFoFumで野良電波拾い。
いえ、悪いことをしようとした訳ではなく、世の中にはどれぐらいWiFiな電波が飛んでいるのか、興味があったのです。

バスはちょうど新宿区内を走っていたのですが、ほんの20分ほどで、なんと186APを掴んでしまいました！


続きを読む

【技術ネタ】 「mixiの秘密」勉強会?

mixiの技術者の方がmixiのシステム構成やアーキテクトについてはてなの勉強会で語られています。
面白い！パブリックなWebシステムを構築しているエンジニアは必見(必聴?)です。

2005年9月21日 はてな、イー・マーキュリー共同勉強会

当然はてなのシステムもプレゼンテーション資料とかが公開されているんですが、そっちはまだ聴いていないので・・(^^;
オープンソース系でどれだけ大規模システムを作れるか、スケールアウトに持ち込めるかが焦点になっていて、たとえ使っているソフトが異なっていたとしても経験者ならどれもうんうんと頷かされる内容でしょう。
決してスマートではないけれどWebシステムはどこも泥臭く苦労して作ったり動かしてるんだなぁというのが具体的なポイントで実感できます。

最後の質問でどのように個々のエンジニアのコーディングの癖や作り方を共通化しているか(=フレームワークの導入をどうするか)とか、百数十台のホスト名の命名方法なんかが出てきて、苦労のポイントはどこも同じなんだなーと思ったり。

なかなか他社システムの構成を聞ける機会は少ないので貴重なサンプルじゃないでしょうか。
こういう機会が世の中的に一杯あると、同じ苦労を色んなところで色々しなくてもよくなるのかも知れませんが、難しいんだろうなぁ(うちの会社も)。

【技術ネタ】 Web2.0対応リストで遊んでみる

blog.bulknews.netからWeb 2.0対応リストです。

ここ半年ばかりは色々なAPIリリースのニュースに事欠かないですが、こうして並べられると壮観ですね。そしてとても便利です。
Google, Yahoo, Amazonは言わずもがな、あまり日本ではメジャーじゃないAPIを眺めていると面白いです。
結構お役立ちどころとしてはhostip.info(IP Lookup)とかPayPal、geocoder(住所地から経度緯度情報取得)などでしょうか。NOAA Weather Service(気象情報)なんかも便利そうです。
全く知らなかったのですが、FedExやUPSもパブリックなAPIを提供しているようで。FedExなんかはどちらかと言うとEDIからの延長みたいなノリなんですね。例えば企業内ポータルやバックオフィスとの連動を狙っているんでしょう。確かにそれは便利そうです。

但し多くは米国内向け情報だったりするのが、残念！
日本でも気象協会にRSSを求める運動とかあるみたいですが、特に地図情報や気象、交通情報など、公的機関とか官公庁でAPIやスタンダードなフォーマットでの情報公開の動きが大きくなると随分世の中変わる気がします。
同時にこんなところが微妙にグローバルスタンダードだの国家間競争力だのに軽く絡んでくるようにも思われ。

その他リストを眺めていて気付いたのが、REST対応は当然として、どのサービスもほとんどの場合SOAPやWSDL対応がされているということ。最近の流れからは結構意外に思う人も多いんじゃないでしょうか。
これについてはまた別の機会に書いてみたいと思います。

ということで、hostip.infoから位置情報を引っ張ってGoogle Maps上にマッピングするPerlスクリプトを書いてみました(もう誰か書いてるかも知れませんが)。

アクセス元IPから位置情報を取得してGoogle Mapsに表示します

こんなのもほんの30分ほどで書けるんだから、いい世の中ですな。。。