ユニクロのTwitter連動キャンペーンサイトで脆弱性騒ぎ発生 66
ストーリー by hylom
怪しいサイトにパスワードを入力するなという話から 部門より
怪しいサイトにパスワードを入力するなという話から 部門より
あるAnonymous Coward曰く、
ユニクロのTwitter連動型キャンペーンサイト「UNIQLO LUCKY LINE」が各所で（セキュリティ的な意味で）話題になっている。ユニクロ側は「パスワード漏えいはない」 と述べているとのこと。
詳細はITmediaの記事が詳しいが、このキャンペーンサイトは「Twitterアカウントを登録してつぶやきを入力すると、キャラクターが画面上で店舗に並び、その旨がTwitterにも投稿される」というもの。キャンペーンサイトではTwitterのIDだけでなく、パスワードも入力する必要がある（Twitterへの連携に使用されるため、平文で保存されると思われる）ことが一部で騒がれていた。
そして次に話題になったのが、キャンペーンサイトで使われているFlashコンテンツがキャンペーンサイトに登録したユーザーの情報を取得しているという点。このFlashコンテンツは「店舗に並んでいるユーザー」を表示するのだが、そのデータはキャンペーンサイト側のサーバーが保存しており、Flashプログラムはこのサーバーと適宜通信してTwitter IDや「並び順」を示す連番、アイコン画像などを取得していた。パスワードを含む個人情報は含まれていないものの、これらの情報にはこのFlashプログラム以外からもアクセスできたため、「脆弱性ではないか」と一部のユーザーが騒ぎ立てる事態となった。
ダメじゃね？ (スコア:4, すばらしい洞察)
だから平分で通信するなって(後述)
漏洩させたわけではないというのは理解するが、平分で通信していたのだから、応募した人の IDとパスワードが盗聴可能な状態で懸賞サイトが構築されていたわけでしょ？
この件ではまとめサイト [uinyan.com]もあるが、オンラインメディアのInternet Watch の続報 [impress.co.jp]を元に考察してみる。
それなら「平分で通信してました」と認めたわけか
ダメでしたって事ね
それはいいんだが
ここがうんと重要！
特に、Internet Watch の画像で https ではなく、 http となっている事に注目！ [impress.co.jp]
URL は http なのに「SSLにより暗号化」してますって安心させようとするのがまずいね。
Flash で SSL で通信、じゃなくて、実際は SSL で通信などしていないのに、Flash で「SSL により暗号化」って表示させてるだけだな。
Re: (スコア:0, 荒らし)
>特に、Internet Watch の画像で https ではなく、 http となっている事に注目！
>URL は http なのに「SSLにより暗号化」してますって安心させようとするのがまずいね。
>Flash で SSL で通信、じゃなくて、実際は SSL で通信などしていないのに、Flash で「SSL により暗号化」って表示させてるだけだな。
httpで閲覧中のページからクライアントからサーバに送信するデータのみhttpsで取り扱う、
というのはごく普通にやることですが、ご存じない？
Re:ダメじゃね？ (スコア:2, すばらしい洞察)
>>httpで閲覧中のページからクライアントからサーバに送信するデータのみhttpsで取り扱う、
そんなことすんなっって話だよ。
その程度のことも理解できないのか。
Re:ダメじゃね？ (スコア:1)
>httpで閲覧中のページからクライアントからサーバに送信するデータのみhttpsで取り扱う、
>というのはごく普通にやることですが、ご存じない？
なぜSSL利用をケチるのか [nikkeibp.co.jp]
Re: (スコア:0)
そんな間抜けなことが、ごく普通に行われているとは知りませんでした。
＃釣りだと信じたい。
Re:ダメじゃね？ (スコア:2, 興味深い)
ニコニコ動画とかも全ページにログインフォームが表示されていた頃はそういう実装だった。
今はログイン用リンクだけで、そこはhttps。
普通とは呼びたくないから、よく見かける残念実装と呼んでおこう。
Re: (スコア:0)
これが「ごく普通」なところには恐ろしくて発注したくないな（笑）
言っちゃ悪いけどこういう馬鹿やってるところって、
それを指摘する人間がいないくらい馬鹿揃いだからだんだん感覚が麻痺していくんだよな。
そのうち常識で考えてダメなものまで「うちじゃ普通だから」って思うようになる。
Re: (スコア:0)
ってことは twitter.com の公式 web インターフェースでログインする場合も
中間盗聴のされているから危険。ってことですかね？
新しいことを叩くのは国民性と言うか美しい伝統というか
Re:ダメじゃね？ (スコア:3, 興味深い)
その通りです。危険ですよ。
入力フォームの時点から、 https://twitter.com/ [twitter.com] となっているべき（そしてユーザは鍵アイコン+ホスト名を確認してからパスワードを入力すべき）です。
ちなみに https://twitter.com/ [twitter.com] からログインできるようですが、 http のコンテンツを含むため鍵アイコンが不完全な状態になりますね…
Re: (スコア:0)
Re: (スコア:0)
寧ろ新しければ無条件に良いと考えることが国民性なんですがね。
#そういう意味では非国民ばかりかw
他の方も指摘してますが危険でしょう。公式だから安全？何それ？
叩かれるのに新しいも古いもありません。
馬鹿であるか否かです。
大体ものごとを新しいとか古いとかいう物差しで計るほうが理解できない。
Re:ダメじゃね？ (スコア:2)
ここまで入り口ページがhttpであるのが危険な理由を記述して「〜だから危険だ」というコメント無し。
「危険だ危険だ！」しか連呼しないって/.er的にどうなのよ。
入り口がMan in the middle攻撃されてるかもしれないでしょ、とか一言いってあげれば議論らしくなるでしょうに。
Re:ダメじゃね？ (スコア:1)
Re: (スコア:0)
いやべつに、そんなことしなくても、パケット改竄するだけですよ。
Re: (スコア:0)
Re: (スコア:0)
正：平文
ごく簡単に言えば (スコア:3, すばらしい洞察)
こういったきわめて危ないサイトで、他のサイトのパスワード要求するところには、絶対にパスワードを記入しないことだね。
内部でなにされているかわからない。会社としていくら「大丈夫です」って言っても、中の人には会社の意に反して危ないことをする人が隠れていたりする可能性もある。
実に簡単なことだが「パスワードは自分以外の他人には教えない」のが、原則ですからね。
そうでなきゃ、パスワードの意味はない。
だから、こういうUNIQLOのような「他のサイトのパスワードを要求するサイトを作る」こと自身、自粛する必要がある。これはシステムを仕事にする人間の最低限のマナーだと思うんだよね。
使う方も、「他のサイトのパスワードを要求するサイト」なんて、使ってはいけない、とは言わないが、かなり気をつけて使う必要がある。少なくとも、パスワードが他人に漏れる可能性を考慮に入れて、使うのは大原則だと思う。Twitter+Facebookなんてのも、例外ではないよ。
Re: (スコア:0)
1) 他サイトのアカウントを入力させるシステムを作った奴とユニクロのセキュリティ意識は非常に低い（コスト意識は高いかもしれない）
2) ユニクロなんてコスト削減で勝負してるような信用に値しない会社に，生のアカウントをホイホイ入力する馬鹿ども
という2点でしょう．
サイトも酷いし，ユーザのリテラシも酷い．
これはだます方も悪いけどだまされるほうも悪いというレベルの話だと思います．
セキュリティ意識にかける馬鹿どものリストが公開されたのは収穫ですね．
Re: (スコア:0)
http://musico.jp/help/faq.aspx?view=d&ty=a&cid=3&iid=4#lnklist10 [musico.jp]
大手音楽配信サイトですら似たような事をやっているので、
ユニクロ特有の問題というより、業界全体の意識が低い気がする。
Re: (スコア:0)
奴らって、企業自体の社会的信頼さえも”コンテンツ”としてパッケージで買えると思ってるから。
M&Aの時代に企業買収でノシ上がってきた連中にとっては、企業活動さえもパッケージ化されたコンテンツなんだろな。
Re: (スコア:0)
端末のMUAにパスワード入れるんじゃなくて、BlackBerryのセンターに
ログインとパスワード渡して、センターがPOPサーバからとってきた
メールを端末に対してプッシュするかたち。
端末が定期的にPOPにアクセスすると電池がとかパケット代が
とかいろいろあるんだろうけど、いくらなんでもそのデザインは
ないだろうと思った。
いくら平文で使うPOPのパスワードだからって、
他人に教えるもんじゃないだろう、と。
なんとなく思い出しただけですが。
Gmailにおける他アカウントからのPOP機能も (スコア:1)
Gmailに限らず多くのウェブメールサービスでは
他のメールアカウントからPOPしてくる機能がありますが、
アレもまぁ仕組みとしては同じですよね。
POPである以上どうしようもないんだろうなぁ。
自分はPOPで引っ張ってくるのではなく
他のメールアカウント側から転送してますが。
屍体メモ [windy.cx]
Re:Gmailにおける他アカウントからのPOP機能も (スコア:2)
ただspamがよく届くアカウントからの転送の場合、そのドメイン全体が拒否される可能性 [srad.jp]があります。
なので自分は仕方なくPOPで引っ張るようにしています。
本当はそうしたくはないのですが。
脳味噌腐乱中…
Re:ごく簡単に言えば (スコア:1)
Writely -> Google Docs
Jotspot -> Google Sites
Urchin -> Google Analytics
買収して、そのままのドメインを継続してる(Youtube)か、完全に取り込まれたかの違いだし、気にすることでもないと思う。
まぁでも、その認証情報を共有してる人・企業が、買収のたびに増えてるってことか。
おそらくは、認証部分は専用の部門がやって、あとはOAuthみたいに、認証済かどうかを各サービスが確認してるだけだろうから、
実際には認証情報(パスワード)はわたってないだろうね。
とりあえず (スコア:0)
TwitterのIDを乗っ取られたくなければ、関係のないサイトでパスワードを入力しない。
脆弱性だと騒ぎ立てるなら、どの情報が取得できることが問題なのか明示すること。
Re:とりあえず (スコア:3, すばらしい洞察)
それはそうだが、そういう意味では関係のないサイトのくせにTwitterのIDとパスワードを
要求するのは、かなり悪質なサイトであるとは言えると思う。
Re:とりあえず (スコア:1, 興味深い)
「言えると思う」ではなくて、悪質です。
悪質なサイトにパスワードを入力するべきではありません。
Twitter文化圏に詳しくない人向けの良くわかる炎上解説（Re:とりあえず (スコア:5, 参考になる)
今回の事案に関しては、悪質である・悪意がある・非常識であるといった批判は適切ではありません。
# 技術屋としての良心があるならOAuthで開発すべきだった、などは適切。
それは、UNIQLOという大型物件かつ炎上しやすい事案であるにもかかわらず、小炎上で留まっている事にも関連があります。
今回の事案は、
1. Twitterではないサービスに、TwitterのIDとパスワードを入力させているという（正しいがいまさらな）指摘
2. IDとパスワードを入れるページが、httpsではないという（正しいがありがちな）指摘
3. FlashからアクセスするDBに制限をかけていないスカタンな実装であるという指摘
という独立な3つからなる複合炎上物件です。
主に、3番の煙を1番,2番を絡めながら煽った結果で炎上という典型的な「正論で叩く＋不安を煽る」事案です。
典型的なのになぜ小炎上かというと、Twitterの歴史と文化圏にその理由があります。
まず、Twitter連携サービスでは、TwitterのIDとパスワードを入力させることは珍しくないです。
理由はTwitterAPIにあります。
2007年4月にTwitterAPIが公開され、2009年3月にOAuthが利用可能になりました。
つまり約2年の間Twitter APIはBASIC認証しか使えず、TwitterAPIを使う全てのサービスはTwitterのIDとパスワードを必要としました。(過去形)
# Twitterの名誉のために付け加えると、2009年8月以降に開発するサービスはOAuth使ってねというアナウンスはあった。（但し義務ではない）
そして、Twitter APIを使うサービスが粗製濫造されたという歴史があります。
とうぜんSSLってなにそれ？というサービスも大量に存在し、TwitterのIDとパスワードを入力させていました。
つまりTwitter文化圏にどっぷりな人間なほど、1番や2番は"良くあること"であって、別に気にするほどではないわけです。
またOAuthの実装がややこしかったこともあり、ほとんど採用が進んでいなかったのも原因の一つでしょう。
# 有名な連携サイトであるTwitpicがOAuthに対応したのは、2010年になってからだったハズ。
以上のことより、「UNIQLO LUCKY LINE」にいち早く登録してしまう人たちは、既に免疫が出来上がっており1番2番を問題として認識できなくなっています。
よって、対象者の殆どが炎上できないという珍しいという状況にありました。
そして、Flashのデータにアクセスできてしまったという3番の問題に関しても、"ふぁぼったー"のようなある法則に基づいてツイートを集めるサービスが山のようにあるため、公開情報をリストにしたモノが漏洩してもさほど気にしない人が多かったわけです。
つまりは、Twitterにどっぷりの当事者は問題として認識できず、煽られて「パスワードが漏れてるの！？」といって小炎上したに留まり、Twitterの歴史やTwitter APIは知らないが、Webサービスを構築する際の常識は知っている人が、時流にのって正論を打つという小類焼と言う現状に繋がります。
まとめとしては「Twitter界隈では良くあるサービス」かつ「Flash作るときはちゃんとデバッグしようぜ」ということになります:-P
# Twitter文化圏では良くある認証方法だし問題ないよねーではなく、ちゃんと技術者がまともに提案すべきだった、という話でもある。
# なお、Twitter APIがBASIC認証のみでスタートしただとか、それでTwitter APIを使うサービスがTwitterのIDとパスワードを求めるだとかは、
# 当時死ぬほど批判されつつもなあなあでみんな使い続けたという経緯があるダケに、とっても懐かしい感じです。
Re:Twitter文化圏に詳しくない人向けの良くわかる炎上解説（Re:とりあえず (スコア:2, 興味深い)
Re: (スコア:0)
つまり「昔からやってた」「みんなやってた」で完全に間違ってることでも正当化するという、ガラケーのかんたんログインなどとまったく同じ日本ではひたすらよくある構図ですね。
ガラケーと違うのはTwitterはグローバルな企業なのでちゃんとBasic認証の廃止に踏み切ることですか。ガラケーの
個体固体識別番号は廃止どころか変更を難しくする始末 [takagi-hiromitsu.jp]ですからね。Re: (スコア:0)
文化圏ねぇ。まぁおれは使わないからどうでもいいけど、
最近のOAuth SPAM事件を見るにつけリテラシー低い人たちには何を与えても無駄という気がする。
Re:Twitter文化圏に詳しくない人向けの良くわかる炎上解説（Re:とりあえず (スコア:3, おもしろおかしい)
(姑息な商人目線からいうと、)そんな正論では商機は生まれません。
リテラシーの低い人はターゲットとしては非常に魅力的です。
宣伝効果は非常に高く、ちょっとしたブームでも桁違いの購買を生むのです。
同等の機能性商品は他にいくらでも(しかもより低価格で)存在するのに、
宣伝やイメージ戦略で一人勝ち状態を作れるのは、ひとえにその成果です。
＞平文で保存されると思われる (スコア:0)
んんん？何か変じゃね？
正しくは「Twitterへの連携に使用されるため、復号可能な形式で保存されると思われる」でしょ？
流石に平文で保存する馬鹿は今時いない・・・よね？
Re:＞平文で保存されると思われる (スコア:1)
復号可能な形式で保存される
どうやって復号するの？パスワード？そのパスワードはどこに保存してあるの？そのパスワードは「復号可能な形式で保存され」てるとか？それって安全なのかな？
Re: (スコア:0)
これは/.Jの記事に対しての、暗号化してたら平文で保存じゃないよね？という指摘です。
平文で通信すんなとかパスワード保存するならハッシュにしろ（今回は無理かもしれないけど）とか、そういうユニクロへの指摘じゃなくて。
Re:＞平文で保存されると思われる (スコア:1)
これは/.Jの記事に対しての、暗号化してたら平文で保存じゃないよね？という指摘です。
それを解った上で、そうだとしても大差ないんじゃないか、という指摘です。ハッシュではダメなケースなんですから。
いや、正直今回のケースをよく理解しているわけじゃないんですが。
Re:＞平文で保存されると思われる (スコア:1)
> それを解った上で、そうだとしても大差ないんじゃないか、という指摘です。
「大差」ではないかも知れませんが、有意な差がありますね。
今回の件で問題となっている3点のうちの1点は「データベースが外部からアクセスできる」ことだそうですから、そこに平文のパスワードが保存されていたとすると、パスワードがそのまま取れますよね。
暗号化(たとえばAESのような復号可能なもの)して保存されていて、仮にその暗号キーがプログラムにハードコーディングされているなどデータベース上に無いとすれば「データベースを外部からアクセスする」ことによっては漏洩されない訳です。
もちろん、「通信が暗号化されていない」という他の問題点により漏洩する可能性もありますが、「暗号化されていない通信の傍受」よりも「外部アクセスを許されているデータベースへのアクセス」の方が敷居が低いですから、有意な差だと思います。
だからデータベースに暗号化されて保存されていると結論するつもりもないですし、問題となっている３点は問題であることには変わりはありません。
(そういう意味では「大差」ではない)
Best regards, でぃーすけ
Re:＞平文で保存されると思われる (スコア:1)
有意な差がありますね。
確かに差はありますね。
仮にその暗号キーがプログラムにハードコーディングされているなどデータベース上に無いとすれば
その仮定は、非常にあやしいですよね。もしその仮定が正しいとしても、その暗号キーは何パターンあるのでしょう？その辺りを考えると
「データベースを外部からアクセスする」ことによっては漏洩されない
と主張するのはちょっと苦しい気がします。自分のパスワードを登録すれば、暗号文と平文の組を一つ入手でき、後は、ローカルで総当り攻撃が可能。暗号キーが一パターンだと、残りすべてのパスワードが復号できます。
暗号キーがデータベース上に無く、何十パターンも使い分けている、ということならまだマシですが、そんなところにまで気が回るなら、データベースを外から自由にアクセスさせるなんて真似はしないような気がします。
ま、差が無いとは言いませんけどね。
来月からはとりあえず心配要らない (スコア:0)
それにしても他サイトのID/PASSを簡単に入力しちゃう人多いんですね。Twitter用画像ろだで一番人気のTwitpicもそうだし。おいらは怖いからoauth認証使えるtweetphotoにしてます。
ただこれも問題あって、tweetphotoにアップロードするアプリ用のoauth鍵をtweetphotoに登録しとかないといけないんですよ。twitterに使う鍵をそのまま登録するとやっぱりダメダメで、tweetphoto用に別アプリ作ってtweetphoto専用のtwitterのoauth鍵取得しなきゃいけないっていう、わけわからん状態にｗ。
つくづくoauthてセンス悪って思ってます。
Re:来月からはとりあえず心配要らない (スコア:4, 参考になる)
TwitpicはOAuthに対応しています。
HIRATA Yasuyuki
Re: (スコア:0)
かなり遅れたけどね。
夜フクロウはそれで一時期YFrogに変更した。
いまでもTwitPicと選択できるのはその名残。
Re:来月からはとりあえず心配要らない (スコア:3, すばらしい洞察)
> それにしても他サイトのID/PASSを簡単に入力しちゃう人多いんですね。
多くの人はtwから始まっているサイトは全部、関連サイトに見えちゃってるんじゃないかな。
Re:来月からはとりあえず心配要らない (スコア:1, 興味深い)
前にTwitterで見かけたネタですけど、Webアプリは兎も角、デスクトップで動くTwitterクライアントであるとか、あるいは個人が作るBOTにOAuthやXAuthはオーバースペックというか使い勝手が悪すぎます。そして面倒なのがあると「私は面倒が嫌いなんだ(CV:速水奨)」という人が必ず出てくるので、そのうちどこかに抜け道が作られちゃう可能性も否定できず。
＃たとえば「共用OAuth→BASIC認証できるゲートウェイ」とか
単純なID＋パスワード認証も条件付きで許容する方法ないんでしょうかね
中村正三郎が褒めてた (スコア:0)
ユニクロのTwitter使ったこれは頭いいねえ [asablo.jp]
でも、 (スコア:0)
ユニクロに対しては漏洩(というか自分で暴露)してるじゃんって解釈でいいの？
12万ものtwitterアカウントとパスワードの入手かぁ。
やるじゃん。
広告流すのはこの前禁止事項になったから、使い道があるか知らないけど。
Re:でも、 (スコア:1)
漏れていないという事かと。
[Internet Watch]ユニクロの行列キャンペーン「Twitterパスワードは保存していない」と説明
http://internet.watch.impress.co.jp/docs/news/20100527_369799.html [impress.co.jp]
Re:でも、 (スコア:1)
Re: (スコア:0)
Re:でも、 (スコア:1)
POST なので、ログフォーマットに細工してなければ残らないはずですね。
危険？！UNIQLO のTwitter 連動イベント
http://blog.livedoor.jp/blackwingcat/archives/1161581.html [livedoor.jp]
UNIQLOのプレスリリースでの公式発表について
http://blog.livedoor.jp/blackwingcat/archives/1162673.html [livedoor.jp]
取り敢えず、自分的にまとめてみました|･ω･)っ
Re: (スコア:0)