  |
はてなキーワード: セッションハイジャックとは
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。
脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。
そしてこれをそのまま発注するかと言われると、多分しないでしょう。
セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。
経営層は中々首を縦には振らないでしょう。
会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。
こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。
また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。
いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。
削れるものをあげていってみましょう。
例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。
そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。
・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。
プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。
ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。
Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。
サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。
そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。
ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。
実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。
Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。
パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。
ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。
ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。
もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。
ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。
NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。
別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。
また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。
考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。
ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。
使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。
OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。
ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。
有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。
SASTになると、RIPS TECH、Contrast Securityなどでしょうか。
上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。
こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。
ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。
また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。
・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。
https://www.nca.gr.jp/member/7icsirt.html
『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。
また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。
グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』
という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。
組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。
日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。
なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。
会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。
で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。
https://www.7pay.co.jp/news/news_20190705_01.pdf
これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。
実際はどうだかわかりませんけど・・・。
これも有り得る話かなあ・・・と。
開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。
ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。
7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session
と厳しい叱責を受けたため、無能の見識を書いてみた。
「聞くは一時の恥、聞かぬは一生の恥」のとおり、
せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存
作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)
確認している間に1時間はかかるからいいやと思ってしまっていた
師はきっとJWT生成直後3秒でユーザーが
と気づいて通報
そして師が2秒で
「これは、セッションハイジャックだ！」
と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している
これは確かにJWTだと厳しそうだ
セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか
(師はログインを即座に検知してセッションを切れるから問題ないのか)
とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている
この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える
これはまずい、自分の今までの見識の甘さを思い知らされた
keyは初回に設定したのみで、定期的な交換を勧める文が見つからない
私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか
JWTはhash化してつないでいる前提で
解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った
https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83
英数字大文字小文字で約60の時は10桁で20万年と書いているが
現代の解析技術は20万倍は速度が出ると仮定して1年として計算する
日本語に直すと60京4661兆7600億年かかる計算となった
実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ
そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか
私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる
まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと
JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく
そのためapiサーバで上記前提で用いた場合に考えたことを書く
webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく
では危険で
JWT送信→セッション(cookie形式?)送信切り替え→セッションからuser_id取得
とりあえず思いついたのは下記だった
tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能な識別子)が含まれる
httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた
(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)
0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない
というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので
JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった
※余談だが、たまに送る回数が少ない方が安全という
攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた
(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)
その前提のため、わざわざ
JWT送信→セッション(cookie形式?)送信→セッションからuser_id取得
で接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる
つまりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった
つまりcookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら
JWT→user_id
でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った
ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが
セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが
それを指していたのであろうか
余談だが、ブコメの雰囲気に日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)
というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが
結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので
正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている
強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか
でも暗号化したらよいのでは、と思った
expを適切に設定しつつ、必要ならアカウントロック機能を入れる
(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)
少なくともapiサーバ→ネイティブアプリに関して、セッションIDを含めても危険性は変わらない
正直webアプリでも大して変わらんのでは、と思っているのは内緒である
受けてきた。
覚えているうちにメモ。
午後Ⅰ
＜問2＞
設問1
……ユーザは正確な時刻は覚えていないものなので「日時」にしてみた。
担当者は、この時点では、XSRFでなく不正ログインを疑っている。
設問2
(1)a.クロスサイトリクエストフォージェリ
(2)b.3
(4)e.confirm f.submit
設問3
(1)イ、ウ
……適当。onmouseoverとかでもイケるらしい。ダメだこれは。
(2)g.セッションハイジャック
＜問3＞
設問1
設問2
(1)a.ウ b.エ c.ア d.イ
(2)e.1 f.3
(3)g.オ
(4)h.IdP i.改ざん
(5)事前にIdPとSP間で情報共有し、信頼関係を構築しているから。
ここだけ設問に『具体的に述べよ』って書いてないので、。
抽象的なやつかなと思ってこれに。
設問3
社外から社内IdPへの通信は、ファイアウォールで禁止されているから
接続元IPアドレスを制限する機能によって、社外からアクセスできないから
……地味にFWという略語はでてきていないので、ファイアウォールと記載。
ここの説明はすごく問題に出そうだったので、ぐりぐりとマークしていたからすぐに気づいた。
午後Ⅱ
＜問2＞
設問1
(2)b.ウ d.ア
設問2
(1)e.プロキシサーバ f.URLがC&Cサーバである通信
(2)g.外部メールサーバ h.外部サーバに転送が成功している通信
(3)外部DNS: 内部DNSサーバからの再帰問合わせを許可しない
……よく分からないけど、TXTレコードってSE作業とか以外で問い合わせあるの？
と思ったので、これを問い合わせるのはマルウェアYかなと。
設問3
(2)ウィルススキャンで異常が検出された場合に、システム部が即時検知できること
……「調査及び着手の早期化」の機能要件＝システム部が迅速検知できる、かな。
A社の問題点として、セキュリティパッチ適用の遅さ（どこの会社でもあるよね～）も
あるけど、今回、社員PCのフルスキャン（毎日12:00。これは頻度高い。）から、
連絡受けてシステム部が検知する13:10まで時間かかっているのも問題かなと。
設問4
設問5
業務LANのサーバ間通信は、日次データ転送で用いるプロトコルのみを許可する
……『日次でデータ転送』もぐりぐりマークしていたので使ってみた。
以上
http://webbingstudio.com/weblog/cms/entry-773.html
小規模の商用サイトでは、フォームを暗号化する際には、共有SSLを利用するのが当たり前となっています。独自ドメインのSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。
とこの記事では書かれていますが、一体どこで「当たり前」なんでしょうか？
SSL証明書の取得費用は、サーバーホスティングによって額がまちまちなのは確かですけれども、
安く独自SSL証明書を取得して利用できるサーバーホスティングは山ほどあります。
WEB制作者として「自分が良く知っているだけ」のサーバーのレンタルをクライアントに押し付けてはいませんか？
また、小規模商用サイトにしても、仮に年額35,000円のSSL証明書をつけ、かつ、月額3,000円のサーバーを借りていたとすると
月額でいえば6,000円くらいの負担ですが、
いくら小規模とはいえ、広報活動の中核をなすWEBサイトであるならば、
月額6,000円をペイできないとすると、
（というか、効果測定をしていないだけ？）
共用SSLのリスクに関して言えば、この記事が引用している、高木浩光氏の書かれている通りではあります。
cookieが取得できてしまう結果として、一番最初に狙われるのは、管理画面へのログイン。
いわゆるセッションハイジャックです。
ログイン状態を乗っ取られた時点で、どんなCMSでも、WEBサイトの改ざんは可能です。
なぜか。
そのコンテンツは多くの場合MySQLに代表されるDBに保存してあります。
したがって、ファイルの改ざんなどを行わずとも、WEBサイトの内容は書き換えることが可能なのです。
「なるほど」と思ってしまうかもしれないので、
早々に訂正していただきたい。
また、この記事にある a-blog cmsというCMSについてはよく知りませんが、
多くのモダンなCMSでは、ほとんどの管理画面ログインにおいて、
セッションハイジャックに対する防衛は行われていますので、
cookieの取得が、即WEBページの改ざんに繋がるような書き方も、
ここも早々に訂正していただきたい。
この筆者さんは、a-blog cmsというCMSを利用されているようだ。
このCMSはどうやら、PHP製ながらPHPのソースを暗号化しているようだ。
こう言ってはなんですが、攻撃者にしてみれば、a-blog cmsを攻略するくらいならMovable TypeやWordPressを攻めた方が楽というものです。
この記述はむちゃくちゃである。攻撃者にしてみれば、誰でも手に入れられるCMSであれば、
a-blog cmsの公式サイトを拝見すると、MySQLを利用しているようで、
ファイルの暗号化はなされていようとも、DBの中身の仕様は丸見えだ。
前提条件として「知っている」「知らない」の差はあれど、攻撃に関して「ラク」というのは
どう考えても楽観的に過ぎる考えだ。
どうも「SSLで確保される安全の領域」について、かなり認識が甘いようだ。
SSLはあくまで、TCP/IPネットワークにおいて通信経路を暗号化するための技術だ。
通信する際に、通信先のサーバーが正しく認証されているかどうか？に必要なのはSSL証明書。
で、ここに書いたとおり、SSLはあくまでサーバーと利用者の通信においての暗号化だ。
この記事に書かれていることは「メールフォームについて」のことのようだが、
サーバーに到達したあとのメールについては安全性をかんがえていますか？
メールは全く暗号化されず平文で送信されるとても脆弱な通信手段だ。
いくらSSLで通信を暗号化しようとも、問い合わせフォームの送信がメールだったとすると…
とこの記事ではかかれていますが、そもそもHTTPやHTTPSの通信を傍受するより遥かに
メールを傍受したほうがラクとも考えられるはず。
CMSの機能に甘んじて、こういったベーシックな問題に考えが及んでいないとすると、
とおもう。
記事に対するつっこみではないですが、
正しくは「TLS」でっせ。
そろってるっつーかなんつーか・・・
ログイン周りなんて、フレームワーク使わなくても、４時間かかるかどうかだよ・・・セッション周り慣れている人という前提なら。
問題なのはページ数が増えたときにすべてのページに間違いなく確実に同じ処理を入れることで
それが複数人のプログラマになっても、守られること。
そうなるとフレームワークの出番ってはなし。
あとは、それこそセッションハイジャックやらセキュリティ対策が時間がかかる。
今回問題なのは、そんな、慣れている人なら、そもそも、いわれなくても入っている。最初に入れておく一般的機能がまったくはいっていないこと。
robots.txtすらおかれていないこと。普通管理画面以下は、万一に備えて、robtos.txtを置く。という知識もないこと。
そして一番問題なのは PCソフト販売会社がその程度の、セキュリティー知識もない会社に発注するほど、セキュリティー知識がないこと。
コレだとすると、発注側にノウハウが無いので、今後も、セキュリティーの向上は見込めない。
こう言っちゃ何だが、ユーザーは訴訟を起こすべきだし、PCソフト販売会社はさっさと、別なまともな会社に頼むか、
プロキシ犯人説でもいいんだが、相当強固にリクエストを無視するプロキシがあったとして、
セッションハイジャックができたらまずいんじゃねーか？
そういう企業プロキシが存在している事は周知の事実なんだから、楽天ほどの商業サイトで決済からんでるんだし
ログイン直後は302で1度飛ばすとか、ランダムなセッションキーをURLのけつにつけるとか、Cache-Control ちゃんと入れるとか、複数の手を使ってプロキシのキャッシュすり抜けようとしたあげく、
どうしても無理そうならjsでランダムハッシュ付きURLから情報取得してセションと一致しないようならhttpsへ逃げるなど多重の手段を講じてもおかしくないだろ？
企業のプロキシをすり抜けられなくて、セッションハイジャックです。でも、それはプロキシが悪いんですは、言いたいことはわかるが、決済系のWebサイトのセリフじゃない。
コメント見る限り、他の企業のプロキシからも同じ現象は再現しているみたいだし、プロキシーのCache-Control を無視する設定のプロキシ対策を忘れたんじゃなかろうか？というのに1票入れとく。
状況がわからんが、もし、Cache-Control を無視するプロキシー対策忘れなら、一般サイトならセーフだが、課金系サイトなら、サイト側のマネージャークラスの責任。
http://gigazine.net/index.php?/news/comments/20090527_rakuten_csv/
10円で販売というのは、システムを悪意に取っているが、特定業者にはCSV形式で個人情報がDLできるようになっていたことと
http://japan.cnet.com/news/sec/story/0,2000056024,20085874,00.htm
などがあるものの、基本的にmixi本体による騒動はなし。
パスワードも平文を送ってくるなどという事は無し
DeNA : http://www.security-next.com/004849.html
モバゲー事態はセキュリティというよりも、青少年育成の観点から問題視される
はてな：有名どころではDoCoMoなどもモバイルのURLをそのまま出したために
セッションハイジャックされた件などが記憶に新しい。
悪徳商法マニアクスが悪徳商法関連の記事を書いたところ、営業妨害としてはてながクレームをもらい
GREE：ウォッチしてないので、知らんｗ
いずれにしろ、mixi GREE DeNAなどは、いわゆる非技術者向けサービスのためにフィッシング詐欺が憂慮されるが、
あまり、フィッシング詐欺（マンインミドル含む）にたいして強固とは言えないのではないか？という疑惑はある。
Yahooや銀行はコレに対抗するためにセキュリティーシールなどを導入している。が、やはり、マンインミドルにたいして
安全かどうかは疑問。
つか、銀行でも、行員による使い込みなどは、たまに起きるし、セキュリティーってなに？って気はする。
あと、某大手、キャリーアが提携していた大型サービスがパスワード平文でおどろいた。
おい、kawango！一般人にも感じがつかめるようにセッション管理について教えてやる
一般の人にとって一番わかりにくいのが
ということ。
「えー、うちのインターネットは常時接続だよ？」とかいう奴は蓬莱の弾幕でも食らっていやがれ。
となる。接続状態（太郎くんのお家にお邪魔している状態）というものは存在しない。とにかく毎回毎回、「ピンポーン」とやって、いちいち要件を伝えないといけない。ちなみに執事はいつも受動的。言われたことしかしない。
さて、もうちょっと高度に
ことも出来る。
好きな人はさすがに一部の友達にしか伝えられないので、山田家の執事は決められたルールに従って、「太郎の様子は万人に伝えても良いが、太郎の好きな人はマブダチにしか伝えてはならない」といった篩い分けをする必要がある。今僕らが話題にしたい「認証」の問題だ。
もちろん人間の執事なら、一度覚えれば、誰がマブダチで誰がそうでないかはわかるわけだが、現実のWebサーバーは杓子定規なので、毎回毎回「名前（ユーザー名）と合言葉（パスワード）」を聞いて、本当にマブダチかどうかを確認する。
マブダチＡ：「太郎君の好きな人って誰？ 僕は《マブダチＡ》、合言葉は《おニャン子》だよ」
マブダチＡ：「その前は誰だったの？」
という面倒な方法をとらないといけない。
要するにページを移動するたびに（ひとつまえの好きな人を聞くたびに）、認証（マブダチ確認）を行う必要がある。
それはめんどくさいから、ある一定期間の間は特殊な記号を使って、認証を楽に済ませましょうというのが、HTTPにおけるセッション管理だ。
さっきの例え話でいくと、
山田家の執事がマブダチAの手間を考えて「毎回お名前と合言葉を言ってもらうのも面倒ですから、このバッジ（セッションID）をお渡ししますので胸に付けてください（クッキーに保存）。それを見ればわかりますから。但し、最後のお問合せから30分以上すぎたらお名前と合言葉をもう一度言ってもらいます（セッションIDの有効期限）。そのときはまた新しいバッジをあげます」となる。
大事なことは、このバッジが一時的にしか使われないものということだ。どのくらいの期限を有効とするかはその家族で決めたルールによる。いずれにせよ、バッジがあれば完全スルーであるので気をつける必要がある。
要するにセッション管理を利用することで、実はマブダチじゃない人にマブダチを騙られるリスクが増すんだ。
毎回毎回、ユーザー名とパスワードを答えるのは面倒だから、バッジでよろしくね！ってなったら、バッジをジャイアンに奪われたり、スネ夫盗み見られたり、出来杉君に気付かないうちに誘導させられたりというリスクが出てきてしまう。それを心配しないといけないんだ。
ここで、もしだよ、マブダチAが、世界で自分だけが持っている変更不可能な情報をバッジの代わりに使ったとしよう。例えばDNAだ。
執事がDNAでマブダチかどうかを判断する。簡単ログインのためにあなたはDNA情報を提供しますか？となる。山田さんの家も、佐藤さんの家も、田中さんの家もDNA情報ひとつで認証を済んでしまうような社会だ。しかもマブダチAを表すDNAはひとつしかない。よって、このDNAを1つコピーするだけでマブダチAになりすませる。hatenaもmixiもNaviTimeもDNA認証を使っているサービスは全部だ。もちろん、このDNA認証を一般のセッション管理と同じように有効期限を設定して、その都度破棄することもできるが……。それはあくまで、善意の執事の場合であって……。DNA情報と本人の個人情報をマッチングして裏でほくそえむ黒執事がいたら……ざわっざわざわ……。
しかも、DNA情報を暗号化せずによこせと言ってる奴もいるッ！な……何を言ってるのかわからねーと思うが、おれも何が目的なのかわからねえ……。オレオレ詐欺だとか、クレジットマスターだとか、そんなチャチなもんじゃねえ……。DNA情報ばら撒きというもっと恐ろしいものの片鱗を味わったぜ……。
わかったか、kawango！
