タイトルが釣りなのは鼻から承知。

携帯サイトの開発の方には既に知れている問題なのかもしれませんが…

気付いたのはユーザからの問い合わせがあったから。

「携帯電話のキャリアを変更したらログインが出来なくなった」というものです。

「以前のメールアドレスとパスワードを入力しようとしたら、パスワードが数字しか入力できないみたいなんですよ」

…え？

そんなバカなことあるかいな、はっはっはと思っていたら

そんなバカなことありました。

公式サイトに注目。

KDDI au: 入力フォーム変換仕様 > <input type=”password”>/<input type=”radio”>/<input type=”checkbox”>

簡単に言いますと、

<input type=”password” />

↑これは

<ENTRY KEY=”PASSWD” FORMAT=”*N” NOECHO=”TRUE” NAME=”__card4″>
<ACTION TYPE=”ACCEPT” TASK=”GO” DEST=”#__card2″> PASSWORD:
</ENTRY>

↑こう変換されるんですって。

HDMLっていう、日本ではauだけが採用している記述方法です。

で、何が問題かと言うと、この部分。

<ENTRY KEY=”PASSWD” FORMAT=”*N” NOECHO=”TRUE” NAME=”__card4″>

僕はHDML知らないので調べてみました。

EZweb XHTML<input>

なになに。「FORMAT=”*N”」は数字のみの入力を受け付ける…

待って下さいよ。

なーんでそう変換しちゃったんでしょうかね！？

これはHDMLの仕様が問題なのではなく、

auが <input type=”password” /> を勝手に数字のみでいいよねって解釈しちゃったのが問題です。

そりゃあ、知ってればHDMLで組めばいいんでしょうけど、なんでauがこういう仕様にしたのか全く意味がわかりません。

教えてえらいひと。

例によって、何か間違いやツッコミあればコメントにてお願い致します。

TechCrunch Japan
3200万人の個人情報漏洩―RockYouのハッカー侵入への対応は最悪

読んで頂ければわかりますが、このケースは本当にひどい。
事件を隠蔽しようとした行為もひどいですが、パスワードの管理は平文で、事件が発覚した後も対処を行なっていないというお粗末ぶり。
しかも原因は簡単なSQLインジェクション脆弱性とのこと。
10年以上も前から分かっていた問題で、知らないでは済まされません。

ここからは推測ですが…

何故このような実装にしていたのか？が問題だと思います。
可能性としては…

１）システム担当者の知識が浅かった
　　→話になりませんが、可能性はゼロではない？
２）パスワードを平文で保存していたほうが楽だった
　　→パスワードのリマインダーメールなどをそのまま送っていたようですから、この可能性は充分にあります。
３）初めから責任をとるつもりがなかった
　　→トンデモな理論ですが、このサイトのプライバシーポリシーを見ると、その可能性も否めないのが怖いところ。

以下、TechCrunch Japanの記事より、プライバシーポリシーの一文です。

Once we receive your transmission of information, RockYou! makes commercially reasonable efforts to ensure the security of our systems.
However,please note that this is not a guarantee that such information may not be accessed, disclosed, altered, or destroyed by breach of any of our physical, technical, or managerial safeguards.

重要な部分を太字にしました。
「頑張るけど盗まれたりしても僕の責任じゃないよ☆」って言ってます。
乱暴の言い方ですが、このプライバシーポリシーはひどい。

システムの設計はどうなっていたのか、プライバシーポリシーは何のためにあったのか、必ず明らかにするべきです。

こんな無責任なWEBを蔓延らせないために。

iモードブラウザ2.0の「かんたん認証」を利用した不正アクセス手法が発見される:モバイル – CNET Japan

今回ニュースになった問題点は、2009年5月以降に発売した端末に搭載されている「iモードブラウザ2.0」にて対応した「JavaScript機能」と、DNSリバインディングという手法を用いて不正アクセスが可能になってしまうとのこと。
なお、「iモードIDによるかんたんログイン、あるいはセッション管理」を行っている場合にのみ発生する脆弱性だそうだ。

FOMAにはSIMカード（FOMAカード）にも固有の製造番号があり、こちらで簡単ログインを実装している場合には発生しないとのことだが…。

そもそも必要なのかどうか、セキュリティとユーザビリティを天秤にかけて考えた結果なのか、その点は前回のエントリーに書いたのでここでは割愛。

今回は、「簡単ログイン機能は便利かもしれないが、その仕組みについて再考が必要なのではなかろうか」ということについて提案したい。

ごく一般的なログインフォームであれば、
１）ユーザ毎にユニークな「ID」と
２）その人だけが知る鍵＝「パスワード」を入力し、
その組合せが一致した段階で初めてログイン成功、となる。

簡単ログイン機能では、この「ID」と「パスワード」の組合せを携帯電話固有番号で置き換えている。
これはあまりに信用しすぎではないだろうか、と思う。
携帯電話固有番号が担える役割は「ID」の部分だけなのでは？
せめて簡単ログイン機能でも「パスワード」の入力は必須、とかにしたらダメなんだろうか？
それだけでユーザビリティは下がりまくって会員数が激減して売り上げが落ちる、と言われるなら仕方ないが、ほんとにそうなのか？？

まぁそれでも脆弱性は発生すると思いますが、携帯電話を紛失したときなどのリスクを考えても、随分マシになるのではないだろうか？

ヘタレSEの一意見にすぎませんが…

是非皆様のご意見を頂きたい。
もしよろしければコメント欄に一言残してくださると幸いです。

10日で覚えるPHPのキソ　第 10 回 セッション（SESSION） | バシャログ。

$_SESSIONがどういう仕組みなのかがわかりやすいです。

簡単に言ってしまえば、

サーバに保存されるデータ（PHPSESSID）
と
COOKIE（クライアントのブラウザ）が保存するデータ

の２つで成り立っているわけです。

さて、この$_SESSION、どういうところが問題になるのか。

羅列してみます。

１）サーバに保存されるデータの問題

$_SESSIONを使ったとき、サーバにはセッションIDが保存されています。
そして、クライアントのブラウザから送信されたセッションIDと一致した場合にデータを復元します。
しかしデフォルトの設定では、
クライアントから送信されたセッションIDが存在しなかった場合、
送信されたセッションIDを新たに作り出します。
ここで、次の記事に紹介されるような危険性が生まれます。

おさかなラボ – strictなシステムに対するSession Fixation対策

問題点を要約すると、

１）ある人が利用したセッションIDを、悪意を持ったユーザが流用する可能性がある。
２）セッション管理を行っていないシステムでは、ログイン機能自体が意味をなさない可能性がある。

…というところでしょうか。（ちょっと強引にまとめてますが）
上記サイトでは、併せて対策案も提案されています。

おそらく対策案は無数に存在します。
ただ、「そういった脅威が存在する」ということを知らなければ、
システムを作る側としては既に負けていると思います。

対策を講じるか否か、その判断が出来ないようではいけませんからね。。

主に自分に言い聞かせる記事でしたｗ