がるの健忘録 このページをアンテナに追加 RSSフィード

2009-11-17

[]Cookie もんすたぁ orz

携帯のCookie周りをちょいと調べてみたです。

…なんていうかドタマが痛いです orz

以下、気力もなく列挙。


・Secure Cookie非対応があるくさい

・一時Cookie(「ブラウザが閉じられるまで有効」ってやつ)非対応があるくさい(まぁ基本あんまり好ましいと思っちゃいないが


auで、ある程度の共有は可能そうだが…「参照できない」「変更と破棄ができない」などが色々あり、事実上きっついっぽ orz

http://kokogiko.net/m/archives/002179.html

  • http領域で作られたsecure属性のないCookieは、httpsに移ると参照できない。
  • https領域で作られたsecure属性のないCookieは、httpに移ると参照はできるが、変更・破棄ができない。
  • さらに、https領域で作られたCookieがhttp接続中に有効期限が切れると、http側で再発行されるため、httpsで参照できなくなる
  • なので事実上auでもhttpとhttps間でまともにはCookie共有できないに等しい

AUでは「Set-Cookieフィールドのmax age(有効残存秒数)で指定」のみ。Expireヘッダが通用しない(ので、PHPでの設定がでけない。まぁ素敵。header関数使って自力でcookieをセットしませう)


SoftBankはhttpとhttps間で一切のCookieが共有できないらしい orz

こんな話も。

http://d.hatena.ne.jp/m_norii/20080806/1218032059

ただし、別の理由で、SSL・非SSLはまたげません。。。

これはSoftBankSSL仕様に起因するんですが、

SoftBank端末でSSLドメインにアクセスすると、単にhttpsになるのではなく、

SoftBankの中間ゲートウェイを介してSSL接続することになります。

例えば、https://example.com/index.html へのリンクは

https://secure.softbank.ne.jp/example.com/index.html

となります*4。

従って、ドメインが変わってしまうので、Cookie引き継げないんです。。。

・「SoftBankの携帯ブラウザは、自発的にCookieは送出しません。サーバからのレスポンスヘッダ Set-Cookie を受け取ると、次のリクエストからCookieを送出します」


ふむぅり…思った以上に「つかえねぇガラパゴスorz

「携帯のセキュリティ関連を再考察」とかってネタで書こうかと思ったですが………挫折 orz

2009-08-06

[][]大切なお話し

注意:文章は「最後まで」読みましょう。


元ネタはこちら。

■ やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合

http://takagi-hiromitsu.jp/diary/20090802.html#p01


なんていいましょうか…まったく高木先生は理解しておりません。

まず経営的視点がない。セキュリティが大切とは言いますが、費用対効果もありますし、囲い込みも重要です。

それに、技術革新によって「初心者でも誰でも簡単にログイン機能のあるWebサイトを作れるようになった」のが契約者固有IDの類なのです。

それを否定しては経営も費用対効果もあったものではありません。

それに、契約者固有IDの類は、携帯では許される流儀/ローカルルールなのです。


そもそも、指摘の仕方が粘着的でいやらしさを感じる。

こんな喧嘩腰な表題付けている時点で、冷静に指摘するつもりは更々ないだろw

流儀が違うことからくるトラブルを片方を基準に退化とかいいきる傲慢さ。






…とまぁ、頑張ってブックマークから言葉を紡いでみましたが…如何でしたでしょうか?

高木先生、ネタとはいえ、暴言を書いてしまった事をお詫びいたします。


で…書いてて正直イラっとしたので、ど真ん中にぶち込むように本音を突っ込みます。


まず。「経営的視点」を考えるならむしろセキュリティは必須です。低いクォリティは常にいろいろなものを害します。お客様から自分まで、一式。

なんていうか…正直「安い技術者を使い倒して摩耗して使い潰す」背景が仄見えるようで以下略、です。


囲い込みと愚行は純粋に別物。


「初心者でも簡単に作れる」危ないモノなんて…欲しくないとは言いませんが。以前も書きましたが、それなら「初心者が作ったのでセキュリティリスクが高い可能性があります」くらいサイトのTopに書きましょうよ。


携帯電話ならIPアドレスも制限されてるしOK」とか考えている人も少なからずいらっしゃるようですが…今度稿を改めますが、それは「ちゃんと堅いガードもできて、セッションIDとかセッション周りの脆弱性とか十分に理解して回避するスキルも持ち合わせる」人間が言う台詞です。「知らない出来ない」の言い訳につかってはいけません。


指摘の仕方云々については…少なくとも私の目には、礼を逸した文章には全く見えなかったのですが。単純に「触られたくない、痛いところを突かれた」から悪感情を持ってしまっているだけなのでは?


流儀云々についてはもはや言うまでもあらず。


「色々なLIFE CARDを山積みでもってる」人が、「問題点を十二分に承知した上で"今回は問題がない"という判断を下した」上で使うのであれば。

で、必要なら「速やかに改修ができる」のであれば(余談ですが。そういう意味で、ニコ動の方々の動きは非常に素晴らしかったのではないだろうか、という印象を受けました)。

セッション管理としては「異質」に属すると思われる、契約者固有IDを用いるのも或いは「一つの手段/CARD」だとは思うのですが。

それは「セッション」という基礎がきちんと出来てから言う台詞であり、使う手段なのではなかろうか、と思います。


型を知り尽くした上で「あえて破る」から型破りなんです、って思うのですが。

そうでないと「形無し」になるだけなのですが。

どんなもんなんですかねぇ?



一言だけ。

携帯もそろそろ「Cookie非対応端末には対応しておりません」てなサイト作っていいんじゃないかなぁ思うですがどうでしょう?

少なくとも「PC系のWebサイト作るノウハウ」がちゃんと使えるだけでも、大分よろしいのではないかと思うのですが。

[][]追記

http://d.hatena.ne.jp/Kimura/20090727/p1

2009/07/24付けで以下のIPアドレスが削除された。

えと……………恐れていた事が!!

( (;゚Д゚) ) ガクガクブルブル


完璧に「崩壊の序曲」来てるなぁ………

2009-05-20

[]携帯なのかPCなのか

割合によくあるこの手の要求について…ちとまじめに掘りこんでみたいかなぁ、と。

要求の根幹は「アクセスしてきたのが携帯なのかPCなのかを知りたい」ってあたり。


で…「なんで」それを知りたいのか、について、概ね二種類が想定できるです。

・絵文字処理その他表示の問題

・契約者固有IDなどと偽装にまつわる問題


次に…前提条件として。

判定方法としては概ね「USER-AGENT」と「from IP」の2種類が考えられるのですが。


USER-AGENTは、キャリアが新しいなにがしかを作ってこないかぎり「新機種が出ようとも気にせずに使える」のですが、一方で偽装が容易です。


from IPは、比較的偽装が困難なのですが(無理な訳じゃないし、これによって成立しうるアタックも十分にある)、ある程度のガードが可能です。

ただ根本的に「キャリアからの情報が信用できない」というネックがありまして。

http://d.hatena.ne.jp/gallu/20081108/p3

http://d.hatena.ne.jp/m_norii/20081106/1225981496

http://d.hatena.ne.jp/gallu/20081111/p1

日々の運用コストも含めて、もの凄く真摯に考えなきゃいかん現実ってぇもんがあります。

ついでに…「どこでチェックを入れるか」も、色々と頭の痛いところです。

っつか、.htaccessは、個人的には「毎回ファイル読み込まれるなんて頭痛がする事されたくない」ので、httpd.confで真っ先に切る機能のひとつですし。

さりとて、PHPで毎回チェックするのも…そのあたりのコードのパースとかのコストを考えると、結構いやなもんです。

とは言っても「httpd.confを書き換える」ってのも個人的に抵抗感ありますし。

おいちゃん的には

・必要なキャリアさん各サイトについて定期的にチェック & mail

・httpd.conf内でIncludeで各キャリアについて別ファイルで管理 & 必要なら書き換えてreload

が一番無難な落としどころ、ですかねぇ。…台数が増えると「手動でreload 」も相当にしんどいので。なにがしか考慮する必要がありますが。


んで。


まず、楽な「絵文字処理その他表示の問題」から。

これは「USER-AGENTに従って処理を振り分ける」で終了。

理由は簡単で。「偽装したら自分が見づらくなるだけ」なので、別に偽装について考慮をする必要性は原子の一欠片ほどもないので。

だとすると、判定としてはUSER-AGENTを用いるのが一番楽。手間がかかり倒すIPで判定せにゃならん理由などまったくありません。


問題は「契約者固有IDなどと偽装にまつわる問題」の場合。

実際私もやりますが。FireFoxあたり使うと、ブラウザレベルで簡単に偽装ができるんですよねいやまぁテストには便利なんですが。

とりあえず考え方としては二つ。

・契約者固有IDなんて使わない:よりコレクト

・デメリットを踏まえた上で、日々の運用までをちゃんと設計した上でIPアドレスによるチェックをする:やむを得ない現実解?

このどちらか、でしょうか。多分。


前者をチョイスしたいのですが…DoCoMoさんとかDoCoMoさんとかDoCoMoさんとかいくつか問題がありますのと(最新機種がCookie対応との事なので少し状況が改善していくであろうことを切に期待しておりますが)。

「ユーザビリティの観点から、かんたんログインが手放せない」とお嘆きの方も多かろうと思う事を考えると…限りなく頭が痛い話でございます。


とりあえず「簡単には相応のリスクが伴うんだよ」という警句くらいは入れておきたいものです orz


[]認証周り

携帯で如何に認証をするか、って話です。


えと…「当サイトではCookieが使えない端末でのご利用は出来ません」とか書けると楽なのですが…Cookieが使えないことで有名な、DoCoMoさんとかDoCoMoさんとかDoCoMoさんとかが…やっと対応したとはいえ、まだまだ世間様にそのマシンが行き渡るにはしばらく時間がかかるでしょう。

また「簡単ログインがイイ!!」ってユーザさんも多い事を考えると…まだまだ気が抜けません。


当然ながらこの手のことに「唯一解」なんて存在しないのですが。

存在しないなりに、いくつか想定のバリエーションくらいは考えておきたいものです…ってのが、このエントリーの趣旨です。


いち:

素直にIDとパスワードを使う。

DoCoMo以外はCookieで行けますし。DoCoMoも、最新機種はいけるみたいですし(機種名Listつくらんとなぁ)。

で、DoCoMoの「滅び行く、Cookie仕様不可な駄目機種」については…PHPであれば output_add_rewrite_var とかを用いるのが、やむを得ない現実解ですかねぇ?

ただ、セッション系のアタックにもの凄く気ぃ使わなきゃいけませんが。


に:

簡単ログインでIPをちゃんと絞る。

現状一番おおいパターンですが…「戻りが必要ないアタック」だと、IPパケット偽装すりゃアタック可能なんですよねぇ orz

重要なところだけでも「糅てて加えてぱすわぁど」とか、ギミックを設置してみたいもんです。


さん:

条件付きで「user-agentあたりの情報と併用」する。

つまり、認証を「契約者固有ID + user-agent」とかにする。

んと…「総当たり攻撃」なら、これで要素数が増えるので、少しマシかなぁ、程度。決めうちに対しては全くの無力。

機種変については「機種変えたら一回メールで認証かけ直すから」とかいうギミックで対処、かなぁ。


よん:

いちとにをユーザに選ばせる。さんはお好みでトッピング可能。

便利と安全と「今夜のご注文は、ドッチ!」


もうちょっと…携帯で実際にアタックされている資料がそろうと対抗策が考えつくのですが(苦笑

とりあえず…こんな所から考察startかなぁ。


突っ込み大歓迎w

2009-05-19

[]刮目して見よ!!

ニュースもとはこちら

http://blogs.yahoo.co.jp/uparupa_x_aquos/folder/991914.html

内の画像(Content-typeがおかしいようなので、localに保存して、jpeg系の拡張子をつけたりしてごらんください)。

http://img2.blogs.yahoo.co.jp/ybi/1/48/7a/uparupa_x_aquos/folder/991914/img_991914_16670779_0?1242547847

iモードブラウザ高機能化

(VGA対応・キャッシュサイズ100KB→500KB・テキストコピー対応

 Javaスクリプト・Cookie対応、など)

奥様。

聞きました?

ご覧になりました?


Cookie対応




ですってよ!!!???

「あの」DoCoMoさんが。


Cookie




ですって。

えぇあの「iモード」なDoCoMoさんが!


Cookie”!!




あらあら まぁまぁ あらまぁまぁ!!

もひとつ おまけに あらまぁまぁ!!


ようやくですわね!!

とっとと全機種バージョンアップしやがれですわ!!

(口調がおかしい…)


ただ…ついでに。JavaScript対応ってあたりが、本格的に怖いんですけれども orz


とはいえ…近日、携帯の認証関連は本格的に考察予定でしたが…えぇ火が付きましたともさ!!

っちゅわけで。乞うご期待w


…ガセネタぢゃないといいなぁ……………

2009-05-14

[][][][]user-agent関連とか

mobile_info

iフォンの判定をいれる


イーモバイル:やる?

http://developer.emnet.ne.jp/useragent.html

http://developer.emnet.ne.jp/ipaddress.html


WILLCOM(ウィルコム)

http://www.willcom-inc.com/ja/service/contents_service/create/lineup/index.html

Mozilla/3.0(WILLCOM or DDIPOCKET;メーカー/機種名/端末Ver/ブラウザVer/キャッシュサイズ)ブラウザ


http://sarabande.info/wiki/User-Agent