Web屋のネタ帳

ドコモがiモードID通知機能を3月末から提供開始らしい で書いた件だが、予定通りドコモが仕様を発表した。

これで携帯３社めでたく似たような機能をそろえてくれたねありがとう！ といいたいところだが、あえて言おう。

SSL使えないじゃん。仕様が中途半端すぎてうんこ。

つまり、https://携帯サイト/hogehoge.jsp?guid=on という風にURLを書いても、 X-DCMGUIDヘッダを受け取れない。

1. そもそものhttps（http over SSL)というものの仕様としては、URLを送り出す前に既にWebサーバとクライアント（携帯端末）の間での暗号化は始まる。
2. ドコモの端末にはそれぞれSSL証明書がプリインストールされているということは、暗号化はドコモのゲートウェイ上で行われるのではなく端末上で行われる。
3. したがって端末とWebサーバとの間の中継点であるところのドコモのゲートウェイサーバはguid=onという文字がurlに付与されているかどうかを判断できないはず。SSL暗号化されているから。
4. したがってhttpsなページでは、https://。。。。/hogehoge.jsp?guid=on とやってもX-DCMGUIDヘッダは受け取れない。

CNET Japanの報道でも次のように書かれている。

「iモードID」が提供開始、一般サイトでもユーザー情報を取得可能に:モバイルチャンネル - CNET Japan

ドコモによれば、URL内にパラメータを記述することでiモードIDを利用できるという。具体的には、「http://xxxx?guid=ON」のように記述する。GET/POSTの両メソッドに対応するという。 ただし、SSL通信時にiモードIDは付与できない。

そこそこ金をかけたサイトであればユーザー認証その他個人情報を含むクリティカルな画面ではSSLくらい使っているだろう。 そのへんの画面がいちばんにiモード機能を使いたい場所なはずなのに、使えないということになる。 それってどうなのよ？＞ドコモの中の人。

なぜ仕様を決める前に、既存のコンテンツプロバイダに意見を求めるということをしないんだろねあそこは？

公式サイト向けには「uid=NULLGWDOCOMO」をつけると同等の機能が使えるというのはあったが、 そのときも同様の問題があったはず。 それを踏まえていれば、こんなことにはならないはずだ。

なお、ソフトバンクとＡＵの場合は、URLに細工などしなくても識別番号を含むヘッダを送り出す仕様のため、こんなことにはなりません。

see also:

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。
• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足

追記：

よーーーーく見たら、 「SSL通信時は、iモードIDは付与できません。」って小さく書いてあったよここに。　＿|￣|○

いや別に大したことじゃないんですが知らない|気づいてない人って意外と多いのかなと。

「開発用のサーバ機器届きました」
「んじゃ適当に環境つくっといて」
「ラジャ」
「環境できました。とりあえずメンバーのアカウントも作っときました。」
「んじゃはじめっか」
「ftpd動いてないぞ。データのアップできんやんけ」
「あ、忘れてました。今開けます」

っていう流れというか会話を今でもよく聞くんだが、ftpって必要かっていうと、必要ないんだよ、という話。 だってsshdさえ動いてればscpコマンドが使えるから。

クライアントだって、UNIXコマンドラインではscpって叩くだけだし、Windows端末なら WinSCPとかあるわけで。スクリーンショット見ただけで使い方の想像はつくだろう。

telnetやめてsshにしようという話はもう当たり前になりつつあるのに、ファイル転送手段の話になるといまだに「ffftpで。。。」とか言っている不思議。

運用の手間の節約、リソース節約、セキュリティ確保の意味でも、サーバで動いてるサービスは少ないほうがいい。

こんなコンテンツがあることはつい最近まで知らんかった。

開発基盤選定における考慮事項の例
(1) プログラミング言語の選択

1) 例えば、PHPを避ける

短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。

こんなのに反応するのは、こだわりすぎ？あげ足取り？過剰反応？

いいや。こだわらなければならないことだし、「おかしい」と声を上げなければならないことである。 なぜならこれは、そのへんの技術屋さんのブログにメモ的に書いてあることではなく、 IPA＝独立行政法人情報処理推進機構＝の「セキュア プログラミング講座」に書かれていることだからだ。

そもそも「例えば、」とかいうその曖昧さはなぁに？

「曖昧さはできる限り排除しましょう」というのがセキュアプログラミングの基本である

なんていうのはそれこそ釈迦に説法だろうに、よりによって「セキュア プログラミング講座」と題したページ上で そんなあいまいな書き方でミスリードを誘うのはＩＰＡのWebサイトに掲げることではまったくない。ありえない。

これを見たセキュリティ担当者（「にわか」の人含む）がこぞって 「PHPはダメです！(perl|java)です！」とかなんとかトンチンカンな断定をはじめることうけあい。プログラミング言語を変えればセキュアになるよ、といったふうなミスリードを誘いすぎる。何年も前に「SSL入れさえすれば大丈夫」といったSSL催眠術が流行った時期があったけど、それに近いことになるだろう。

だいたい、んなこと言い始めたらなんでもありでしょうが。

「例えば、」

IIS+ASP(ActiveServerPage)で書かれたサイトだって相当おかしなコードが多くてヨワヨワな場合が多いのはこの業界の人なら誰もが薄々わかっていることなわけで。（しかもその手の予想はたいていあたってる）

「経緯」

とか言う単語をこういう形で出すのが許されるんであれば、 何年か前までさかのぼればカカクコム（IIS+ASPで構築されてた）の事件の件とか、 ごく最近で言えば、IIS+ASP(+SQLServer)を狙った攻撃が多発して、トレンドマイクロのウィルス情報のページがウィルス汚染されたというナイス洒落な件をも「経緯」としてひもといたほうがインパクトあるんじゃなかろうか。

ならば、「例えば、IISとActiveServerPageを避ける」とか書きますか？

っていうとそんな書き方はしないわけですよ。よしんば書いたところですぐひっこめなきゃならないことになる。なんでって？そりゃぁあなた．．．（笑）

ニュートラルな立場で啓蒙活動をしなければならないはずの公益目的の団体や組織が、 いつのまにやらevil（邪悪）になっていくサマはspamhaus.orgなんかと同じだ。 そこまで言うのはオーバー？いいや。意外と簡単に落ちてしまうのがダークサイドの誘惑というものである。 用心すべきは用心すべきだし、声を上げるべきは声をあげるべきだろう。 巷のブログ（このブログ含め）などに書き散らかしてあるのとはわけが違うのだから。

ＩＰＡのこのコンテンツの件とはまったく別の記事の話だが、PHP界隈で著名な大垣氏が 「誤解を招く記事 - LAMPセキュリティを強化する4つの方法」という記事を書いている。技術的に見てもかなり納得が行く。なによりも、結びが秀逸だ。その一文を借りてこの記事も終えることにする。

「言語を替える事はセキュリティ問題の解決策にはなりません。」

see also:

• LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠 (yohgaki's blog 2008/3)
• 「例えば、PHPを避ける」ってなぁにその曖昧な書き方？ (yohgaki's blog 2008/3)

個人的にJavaが嫌いとかいうことではないし、事実、筆者もJavaで書くことが普通によくあるんだが、

Java が使いにくいのは静的だからではない

あと、アクセッサね。いちいち getter と setter を定義しなきゃいけないのがバカバカしい。よく「IDE で自動生成すれば問題ない」という人がいるけど、そんなのが必要な時点で間違ってるとは思わないのだろうか。だいたい、本質的でないコードが何十行もある時点で、ソースコードの readability が下がってしまう。あんなもの、コード行数を水増しするための仕様だ。

あっはっは。同意同意。「IDEで自動生成すれば．．．そんなのが必要な時点で間違ってる」のあたり特に。 どうにかならんもんかねまったく。

とは言っても、大人数でよってたかって開発するときにはその冗長さ（？）が時には必要悪になるといえばなるのかなあ。

see also: Javaジャバ言ってる間にも