Mobileクラスの問題点
Tietew
ケータイIDの話題を出したので、ここいらで少し書いてみます。
★iモードブラウザ2.0端末はCookieを扱える
cf. http://www.nttdocomo.co.jp/service/imode/make/content/browser/browser2/index.html
iモードブラウザ2.0かどうかは以下のように取得できる：
cache = @request.env["HTTP_USER_AGENT"][/^DoCoMo\/2\.0 \w+\(c(\d+)/, 1]
cache && cache.to_i >= 500
★SSL
cf. http://takagi-hiromitsu.jp/diary/20100428.html
SSL経由で取得したケータイIDを使ってはならない。
@request.ssl? ならば各種ID取得メソッドはnilを返すべき。
また、IPアドレスチェックを強制したほうが良い
★SoftBankの端末シリアる番号は偽装できる
cf. http://takagi-hiromitsu.jp/diary/20100427.html
IPアドレス制限は無意味。
★消滅したもの
SoftBank2G, cdmaOne は消滅した。
--
Tietew <tie...@gmail.com>
// Powered by GMail
Shin-ichiro OGAWA
> ★iモードブラウザ2.0端末はCookieを扱える
> cf. http://www.nttdocomo.co.jp/service/imode/make/content/browser/browser2/index.html
> iモードブラウザ2.0かどうかは以下のように取得できる：
> cache = @request.env["HTTP_USER_AGENT"][/^DoCoMo\/2\.0 \w+\(c(\d+)/, 1]
> cache && cache.to_i >= 500
まあこれはやっておくべきかなとは思ってます。
> ★SSL
> cf. http://takagi-hiromitsu.jp/diary/20100428.html
> SSL経由で取得したケータイIDを使ってはならない。
> @request.ssl? ならば各種ID取得メソッドはnilを返すべき。
> また、IPアドレスチェックを強制したほうが良い
jpmobileでやるべきかどうかは、正直良くわかりません。
そもそもSSL経由でアクセスできないようにすべきで、
ここで対処してもごまかす方法はいくらでもあります。
> ★SoftBankの端末シリアる番号は偽装できる
> cf. http://takagi-hiromitsu.jp/diary/20100427.html
> IPアドレス制限は無意味。
高木さんの記事では、「https://とhttp://の両方でアクセスできる場合に」、
「接続元IPアドレスが正規のものであっても信頼できない」ということです。
なので、無意味ではありません。
こちらも基本的にはアプリケーション側でなんとかすべきだと思います。
> ★消滅したもの
> SoftBank2G, cdmaOne は消滅した。
SBの2Gは消滅しましたが、cdmaOneは消滅してません。
新規契約できないだけで、まだありますよ。
一般的には消滅扱いでも良いかもしれませんが、
少なくとも私が所属する会社ではそうはできません。
あと、上記は理想的なのですが、
互換性が無くなるので、次の大きな変更(Rails 3.0?)でもないと、
対応しきれないなーと言うのもあります。
--------
小川 伸一郎 (Shin-ichiro OGAWA)
rust....@gmail.com
GPG ID 94B70E36 / 75360751
fingerprint: {C64E 9826 8A75 723E DE54 / 70A8 F623 220C 94B7 0E36}
http://stnard.jp/
http://twitter.com/conceal_rs/
http://iddy.jp/profile/rust/
2010/6/21 Tietew <tie...@gmail.com>:
> --
> このメールは Google グループのグループ「jpmobile」の登録者に送られています。
> このグループに投稿するには、jpmo...@googlegroups.com にメールを送信してください。
> このグループから退会するには、jpmobile+u...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/jpmobile?hl=ja からこのグループにアクセスしてください。
>
>
Tietew
>> ★SSL
>> cf. http://takagi-hiromitsu.jp/diary/20100428.html
>> SSL経由で取得したケータイIDを使ってはならない。
>> @request.ssl? ならば各種ID取得メソッドはnilを返すべき。
>> また、IPアドレスチェックを強制したほうが良い
>
> jpmobileでやるべきかどうかは、正直良くわかりません。
> そもそもSSL経由でアクセスできないようにすべきで、
> ここで対処してもごまかす方法はいくらでもあります。
フールプルーフという奴です。
回避方法はあるとしても、それは故意に回避しているわけで、事故っても回避した奴の責任です。
ライブラリとして防止しておくことに意味はあると思います。特に下のような状況で。
request.mobile? && request.mobile.valid_ip? && !request.ssl? ?
request.mobile.ident_subscriber : nil
とかいちいち書くのは面倒です。
>> ★SoftBankの端末シリアる番号は偽装できる
>> cf. http://takagi-hiromitsu.jp/diary/20100427.html
>> IPアドレス制限は無意味。
>
> 高木さんの記事では、「https://とhttp://の両方でアクセスできる場合に」、
> 「接続元IPアドレスが正規のものであっても信頼できない」ということです。
> なので、無意味ではありません。
いいえ。違います。このページには話題が二つ書いてあります。
まず、「端末シリアル番号を認証に使ってはいけない」の節。
「端末シリアル番号」の偽装が、「http下でIPアドレス制限をしていても」成立するという話題です。
こちらはhttpsかどうかは関係ありません。
次に、「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」の節。
httpなページがhttpsでも閲覧できるようになっていると、意図せず、
httpsに着た端末IDを信用してしまう実装がされている可能性があるので、
SSLかどうかをチェックしなければならないという話題です。
なお、docomo/auに関しては、iモード/ezwebネットワークのAPNが割れていないので、
今のところ偽装の手段は見つかっていません。
が、EMnetに関してはAPNとプロクシが割れているので、x-em-uidヘッダの偽装ができるそうです。
> こちらも基本的にはアプリケーション側でなんとかすべきだと思います。
原理的にはその通りですが、積極的に提供すべきものではないと思います。
>> ★消滅したもの
>> SoftBank2G, cdmaOne は消滅した。
>
> SBの2Gは消滅しましたが、cdmaOneは消滅してません。
> 新規契約できないだけで、まだありますよ。
> 一般的には消滅扱いでも良いかもしれませんが、
> 少なくとも私が所属する会社ではそうはできません。
WAP1.0端末のことなのですが、停波していませんでしたっけ？
デバイス名的に言うと、/^[A-Z]{2}[1T]/ なやつ。
> あと、上記は理想的なのですが、
> 互換性が無くなるので、次の大きな変更(Rails 3.0?)でもないと、
> 対応しきれないなーと言うのもあります。
それはそれでよいと思います。
色々手を入れたい箇所もありますし、特に、case-whenでキャリア分岐している箇所。
あれはMobileクラスへ委譲すべき。
Shin-ichiro OGAWA
> フールプルーフという奴です。
> 回避方法はあるとしても、それは故意に回避しているわけで、事故っても回避した奴の責任です。
> ライブラリとして防止しておくことに意味はあると思います。特に下のような状況で。
> request.mobile? && request.mobile.valid_ip? && !request.ssl? ?
> request.mobile.ident_subscriber : nil
> とかいちいち書くのは面倒です。
「ライブラリ側でいろいろやると、ハマったときにソースコードを全部見なければいけない」のは避けたいので、
面倒でも意識してやってもらう方がいいと思ってます。
なのでFoolProofだからといってjpmobile側でやってしまうことには賛成できません。
> まず、「端末シリアル番号を認証に使ってはいけない」の節。
> 「端末シリアル番号」の偽装が、「http下でIPアドレス制限をしていても」成立するという話題です。
> こちらはhttpsかどうかは関係ありません。
こちらは誤解していたようです。
User-Agent のを見ていた場合に、IPアドレスが有効アドレスかチェックしても信頼性がないと言うことですね。
ただそれと「IPアドレス制限しても意味がない」と言うこととは違いますよね。
そうすると「端末シリアル番号を認証に使ってはいけない」のはアプリケーション側で、
jpmobile側では特に何もできないと思うのですが。
> 次に、「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」の節。
> httpなページがhttpsでも閲覧できるようになっていると、意図せず、
> httpsに着た端末IDを信用してしまう実装がされている可能性があるので、
> SSLかどうかをチェックしなければならないという話題です。
こちらもIPアドレス制限ではなく、httpsか否かということでしょうか。
> 原理的にはその通りですが、積極的に提供すべきものではないと思います。
jpmobileとしては、少し複雑なことをしなければならないことを、
かんたんに提供するだけでいいのではと思ってます。
あれこれライブラリ側でやってあげるのは親切ではありますが、
あんまりやり過ぎるとメンテナンスが大変になるので、
そこまでやらなくてもいいのではないでしょうか。
> WAP1.0端末のことなのですが、停波していませんでしたっけ？
> デバイス名的に言うと、/^[A-Z]{2}[1T]/ なやつ。
停波したという話はまだ聞いたことがないのでわかりませんが、
どこかにニュースリリースとかありました？
とりあえずアクセス状況など調べてみます。
--------
小川 伸一郎 (Shin-ichiro OGAWA)
rust....@gmail.com
GPG ID 94B70E36 / 75360751
fingerprint: {C64E 9826 8A75 723E DE54 / 70A8 F623 220C 94B7 0E36}
http://stnard.jp/
http://twitter.com/conceal_rs/
http://iddy.jp/profile/rust/
2010/6/23 Tietew <tie...@gmail.com>:
yosuke
>> WAP1.0端末のことなのですが、停波していませんでしたっけ？
>> デバイス名的に言うと、/^[A-Z]{2}[1T]/ なやつ。
>
> 停波したという話はまだ聞いたことがないのでわかりませんが、
> どこかにニュースリリースとかありました？
cdmaOne(800MHz帯) は現役ですが、HDML 専用機からの Web 接続サービスは終了しています。
わかりにくいのですが、ニュースリリースは下記が該当すると思います。
au携帯電話における「EZweb@mailコース」の提供終了について:
http://www.kddi.com/corporate/news_release/2007/1022a/
したがって、HDML 専用機向けの機能は必要ないかと。(jpmobile にありましたっけ。)
あと、「停波」という文脈だと、以下のリリースが参考になるかもしれません。
800MHz帯の周波数再編に伴う「CDMA 1X」などのサービス終了等のお知らせ
http://www.kddi.com/corporate/news_release/2010/0405a/besshi.html
au は 2G から 3G への移行時に 800MHz 帯をそのまま引き継いだため、
電磁波帯域の話とブラウザの話を混同してしまいがちですよね。
何か参考になれば。ではでは。
--
yosuke / tmt...@gmail.com
Shin-ichiro OGAWA
> cdmaOne(800MHz帯) は現役ですが、HDML 専用機からの Web 接続サービスは終了しています。
> わかりにくいのですが、ニュースリリースは下記が該当すると思います。
>
> au携帯電話における「EZweb@mailコース」の提供終了について:
> http://www.kddi.com/corporate/news_release/2007/1022a/
>
> したがって、HDML 専用機向けの機能は必要ないかと。(jpmobile にありましたっけ。)
なるほど、停波はまだだけどWebアクセスができないってことですね。
いまのところ、HDML専用機向けの機能はないはずなので大丈夫そうです。
ありがとうございます。
--------
小川 伸一郎 (Shin-ichiro OGAWA)
rust....@gmail.com
GPG ID 94B70E36 / 75360751
fingerprint: {C64E 9826 8A75 723E DE54 / 70A8 F623 220C 94B7 0E36}
http://stnard.jp/
http://twitter.com/conceal_rs/
http://iddy.jp/profile/rust/
2010/6/23 yosuke <tmt...@gmail.com>:
Tietew
>> フールプルーフという奴です。
>> 回避方法はあるとしても、それは故意に回避しているわけで、事故っても回避した奴の責任です。
>> ライブラリとして防止しておくことに意味はあると思います。特に下のような状況で。
>> request.mobile? && request.mobile.valid_ip? && !request.ssl? ?
>> request.mobile.ident_subscriber : nil
>> とかいちいち書くのは面倒です。
>
> 「ライブラリ側でいろいろやると、ハマったときにソースコードを全部見なければいけない」のは避けたいので、
> 面倒でも意識してやってもらう方がいいと思ってます。
> なのでFoolProofだからといってjpmobile側でやってしまうことには賛成できません。
私の提案の根底には、高木先生の言う、「ケータイ脳」汚染を広げない為にはどうすればよいか、
というものがあります。
現状、端末IDを見るときにはSSL「でないこと」を確認すべし、という情報は広まっているとは思えません。
ライブラリが機能を提供していると、何も考えずに（ドキュメントも読まず）使ってしまう人が増えると思います。
そのため、ライブラリ側でできるだけ安全側に倒し、使用すべきでない機能を積極的に「提供しない」
ことによって、この連鎖を止める手助けになれば、と思うのです。
私は逆に、ライブラリ側の責務くらいに考えたいです。
>> まず、「端末シリアル番号を認証に使ってはいけない」の節。
>> 「端末シリアル番号」の偽装が、「http下でIPアドレス制限をしていても」成立するという話題です。
>> こちらはhttpsかどうかは関係ありません。
>
> こちらは誤解していたようです。
> User-Agent のを見ていた場合に、IPアドレスが有効アドレスかチェックしても信頼性がないと言うことですね。
>
> ただそれと「IPアドレス制限しても意味がない」と言うこととは違いますよね。
> そうすると「端末シリアル番号を認証に使ってはいけない」のはアプリケーション側で、
> jpmobile側では特に何もできないと思うのですが。
提案としては、端末シリアル番号の取得を削除する、ですね。
これも、使用すべきでない機能を提供しない、と言う意図です。
>> 次に、「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」の節。
>> httpなページがhttpsでも閲覧できるようになっていると、意図せず、
>> httpsに着た端末IDを信用してしまう実装がされている可能性があるので、
>> SSLかどうかをチェックしなければならないという話題です。
>
> こちらもIPアドレス制限ではなく、httpsか否かということでしょうか。
こちらは、そうです。IPアドレス制限＋SSL「ではない」のチェックが「必須」ということです。
SoftBankだけでなく、EMOBILEでも同様です。
>> 原理的にはその通りですが、積極的に提供すべきものではないと思います。
> jpmobileとしては、少し複雑なことをしなければならないことを、
> かんたんに提供するだけでいいのではと思ってます。
> あれこれライブラリ側でやってあげるのは親切ではありますが、
> あんまりやり過ぎるとメンテナンスが大変になるので、
> そこまでやらなくてもいいのではないでしょうか。
セキュリティは「かんたん」に拘ると穴が空いてしまいます。
「ケータイ脳」問題もそうです。できるだけ利用者が簡単になるようにと追求した結果、
大穴が空いてしまいました。
SSLかどうかのチェック、IPアドレス制限もその「少し複雑」なうちの中で、「必ずすべきこと」
となっていますので、ライブラリに組み込むべきだと思います。
>> WAP1.0端末のことなのですが、停波していませんでしたっけ？
>> デバイス名的に言うと、/^[A-Z]{2}[1T]/ なやつ。
>
> 停波したという話はまだ聞いたことがないのでわかりませんが、
> どこかにニュースリリースとかありました？
> とりあえずアクセス状況など調べてみます。
周波数帯の話とサービスの話が混同していましたね。
富田さんのメールで正しいと思います。
乳牛
なんだか議論が端末ID=認証用みたいな流れになっているように読めますが、
端末IDって認証以外の目的にも利用することが有りますよね。
> 提案としては、端末シリアル番号の取得を削除する、ですね。
> これも、使用すべきでない機能を提供しない、と言う意図です。
なので、ここまで行ってしまうと少々行き過ぎかと思います。
jpmobileとして「端末IDを取る手段を提供する」のは悪くはないと思います。
その端末IDを何に使用するかは使い手の問題であるわけで。
>>> フールプルーフという奴です。
>>> 回避方法はあるとしても、それは故意に回避しているわけで、事故っても回避した奴の責任です。
どのくらいフールな人を救ってあげるかはプロダクトオーナーの判断にお任せな
わけなんですが、
>>> ライブラリとして防止しておくことに意味はあると思います。特に下のような状況で。
>>> request.mobile? && request.mobile.valid_ip? && !request.ssl? ?
>>> request.mobile.ident_subscriber : nil
>>> とかいちいち書くのは面倒です。
ここに関しては、 request.safe_ident_subscriber とかあるといいかもしれませんね。
信頼に値する時しかidentが取れない、みたいな仕様で。
まぁ、それよりもパブリックな識別子を秘密鍵だと錯覚しているトホホな技術者が
わんさかいるのが一番の問題なんだとは思いますけどね。。。
2010年6月23日16:17 Tietew <tie...@gmail.com>:
Shin-ichiro OGAWA
> 提案としては、端末シリアル番号の取得を削除する、ですね。
> これも、使用すべきでない機能を提供しない、と言う意図です。
これはUserAgentからのものだけではなく、全てですか？
それであれば賛成できません。
また提供しないと提供するライブラリが現れるだけじゃないでしょうか。
どちらかというと、
> ここに関しては、 request.safe_ident_subscriber とかあるといいかもしれませんね。
> 信頼に値する時しかidentが取れない、みたいな仕様で。
という感じか、やるとしても、
オプションで安全側に振り切るか、そうでないか選べる方が良いと思います。
なんか「ライブラリ側で制限かければ、アレな開発者はいなくなる」という
主張にも見受けられるのですが、
逆に「これはダメだよ」と啓蒙しなければ、アレな人はアレなままではないでしょうか。
例えば安全でない場合に取得しようとすると、ログやSTDOUTにWarningを出す方が
啓蒙になって良いような気もします。