「セッションハイジャック」を含む日記 RSS

はてなキーワード: セッションハイジャックとは

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)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というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツール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は社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ このエントリーをはてなブックマークに追加ツイートシェア

2019-01-29

anond:20190129122704

流出したのはパスワードじゃなくてアクセストークンだけどな。

アクセストークンだけだと、それに紐づくコンシューマーキーがないと使えないはずなんだけど、そこはどうなんだろう?

セッションハイジャックができるようなら話は変わってくるが。

2019-01-23

togetterで飛ばされる先

togetterを見ていると、フィッシングサイトに度々飛ばされるんだけど、さっきは楽天(本物)に飛ばされた。

URIセッションIDっぽい物が付いてたかセッションハイジャック狙い?できるの?

謎だ。

2018-09-22

JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当コメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意セッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザー

「これは、セッションハイジャックか・・・!?

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ!」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッション任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記懸念全てにきれい対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字keyが生成された

解読時間は下記を参考に、計算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を10乗した時点で(20文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッションIDを含めれば安全」に関する私見

から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークン実装しなかったことを告白しておく

そのためapiサーバ上記前提で用いた場合に考えたことを書く

webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険

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だろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメント発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意サーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初段落問題と同一と思っている

余談だが、ブコメ雰囲気日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的結論

expの期限と任意セッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッションIDを含めれば安全」について

少なくともapiサーバネイティブアプリに関して、セッションIDを含めても危険性は変わらない

正直webアプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたしま

2017-04-17

情報処理安全確保支援士_20170416午後解答メモ

受けてきた。

覚えているうちにメモ

午後Ⅰ

<問2>

設問1

  L氏の確認内容 :退会処理完了までのログイン回数と日時

  ログイン記録から:退会処理完了までのログイン時刻

……ユーザは正確な時刻は覚えていないものなので「日時」にしてみた。

  担当者は、この時点では、XSRFでなく不正ログインを疑っている。

設問2

(1)a.クロスサイトリクエストフォージェリ

(2)b.3

(3)c.現在パスワード d.知りえない

(4)e.confirm f.submit

設問3

(1)イ、ウ

……適当。onmouseoverとかでもイケるらしい。ダメだこれは。

(2)g.セッションハイジャック

(3)h.スクリプト実行を禁止する。

……ありがちな答え。あとで考えると、サニタイズする、かも。

<問3>

設問1

 接続IPアドレスがF社のIPアドレス以外のもの

……『F社のプロキシサーバIP』まで書いてもよかった。

設問2

(1)a.ウ b.エ c.ア d.イ

(2)e.1 f.3

(3)g.オ

……ここは、ウ(クエリラメタ)が正しそう。

(4)h.IdP i.改ざん

(5)事前にIdPとSP間で情報共有し、信頼関係を構築しているから。

……『レスポンスを中継しているから』とか思ったけど、

  ここだけ設問に『具体的に述べよ』って書いてないので、。

  抽象的なやつかなと思ってこれに。

設問3

 交通費精算サービス:3

 社外から社内IdPへの通信は、ファイアウォール禁止されているか

 グループウェアサービス:1

 接続IPアドレス制限する機能によって、社外からアクセスできないか

……地味にFWという略語はでてきていないので、ファイアウォール記載

  ここの説明はすごく問題に出そうだったので、ぐりぐりとマークしていたからすぐに気づいた。



午後Ⅱ

<問2>

設問1

(1)a.SMTP over TLS

(2)b.ウ d.ア

(3)c.内部メールサーバ

設問2

(1)e.プロキシサーバ  f.URLがC&Cサーバである通信

(2)g.外部メールサーバ h.外部サーバ転送成功している通信

(3)外部DNS: 内部DNSサーバから再帰問合わせを許可しない

  内部DNS: 外部DNSDNS問合せしない

……内部のは間違っていそう。同じ内容だしかぶってるし。

(4)i.TXTレコードに対する問合せ

……よく分からないけど、TXTレコードってSE作業とか以外で問い合わせあるの?

  と思ったので、これを問い合わせるのはマルウェアYかなと。

設問3

(1)ファイル暗号化しないこと

(2)ウィルススキャンで異常が検出された場合に、システム部が即時検知できること

……「調査及び着手の早期化」の機能要件システム部が迅速検知できる、かな。

  A社の問題点として、セキュリティパッチ適用の遅さ(どこの会社でもあるよね~)も

  あるけど、今回、社員PCのフルスキャン毎日12:00。これは頻度高い。)から

  連絡受けてシステム部が検知する13:10まで時間かかっているのも問題かなと。

設問4

 j.PC-LAN

設問5

業務LANサーバ通信は、日次データ転送で用いるプロトコルのみを許可する

……『日次でデータ転送』もぐりぐりマークしていたので使ってみた。

以上

2015-08-07

一体なんだよこの記事

http://webbingstudio.com/weblog/cms/entry-773.html

知ってか知らずかちょっとこの記事ひどいので、突っ込む。

共用SSL証明書が当たり前?

小規模の商用サイトでは、フォーム暗号化する際には、共有SSLを利用するのが当たり前となっています独自ドメインSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。

とこの記事では書かれていますが、一体どこで「当たり前」なんでしょうか?

SSL証明書の取得費用は、サーバーホスティングによって額がまちまちなのは確かですけれども、

安く独自SSL証明書を取得して利用できるサーバーホスティングは山ほどあります

WEB制作者として「自分が良く知っているだけ」のサーバーレンタルクライアント押し付けはいませんか?

また、小規模商用サイトにしても、仮に年額35,000円のSSL証明書をつけ、かつ、月額3,000円のサーバーを借りていたとすると

月額でいえば6,000円くらいの負担ですが、

いくら小規模とはいえ、広報活動の中核をなすWEBサイトであるならば、

月額6,000円をペイできないとすると、

ちょっと商用サイトとしては破綻しているように感じます

(というか、効果測定をしていないだけ?)

改ざん認識

共用SSLリスクに関して言えば、この記事引用している、高木浩光氏の書かれている通りではあります

cookieを取得できてしまうという点においては。ですね。

で、その部分の帰結が、完全におかしい。

cookieが取得できてしまう結果として、一番最初に狙われるのは、管理画面へのログイン

いわゆるセッションハイジャックです。

ログイン状態を乗っ取られた時点で、どんなCMSでも、WEBサイト改ざんは可能です。

なぜか。

CMSは「コンテンツマネージメント」する仕組みで、

そのコンテンツは多くの場合MySQL代表されるDBに保存してあります

したがって、ファイル改ざんなどを行わずとも、WEBサイトの内容は書き換えることが可能なのです。

WEBアプリケーションの仕組みに明るくない方が読むと

「なるほど」と思ってしまうかもしれないので、

早々に訂正していただきたい。

また、この記事にある a-blog cmsというCMSについてはよく知りませんが、

多くのモダンCMSでは、ほとんどの管理画面ログインにおいて、

セッションハイジャックに対する防衛は行われていますので、

cookieの取得が、即WEBページの改ざんに繋がるような書き方も、

CMS利用者に対して、誤解を広げる結果になりそうですので、

ここも早々に訂正していただきたい。

CMSを過信していないか?

この筆者さんは、a-blog cmsというCMSを利用されているようだ。

このCMSはどうやら、PHP製ながらPHPソース暗号化しているようだ。

なるほど、それならばファイル改ざんは確かに起きにくい。

が、それはあくまで起きにくいだけの問題

こう言ってはなんですが、攻撃者にしてみれば、a-blog cms攻略するくらいならMovable TypeWordPressを攻めた方が楽というものです。

この記述むちゃくちゃである攻撃者にしてみれば、誰でも手に入れられるCMSであれば、

ファイル構造の解析はそんなに難しい話ではない。

a-blog cms公式サイトを拝見すると、MySQLを利用しているようで、

ともすれば、インストールさえしてしまえば、

ファイル暗号化はなされていようとも、DBの中身の仕様は丸見えだ。

前提条件として「知っている」「知らない」の差はあれど、攻撃に関して「ラク」というのは

どう考えても楽観的に過ぎる考えだ。

安全」の認識

最後に突っ込んでおきたい。というか質問というか。

どうも「SSLで確保される安全領域」について、かなり認識が甘いようだ。

SSLあくまで、TCP/IPネットワークにおいて通信経路を暗号化するための技術だ。

通信する際に、通信先のサーバーが正しく認証されているかどうか?に必要なのはSSL証明書

で、ここに書いたとおり、SSLあくまサーバー利用者通信においての暗号化だ。

この記事に書かれていることは「メールフォームについて」のことのようだが、

サーバーに到達したあとのメールについては安全性をかんがえていますか?

メールは全く暗号化されず平文で送信されるとても脆弱通信手段だ。

いくらSSL通信暗号化しようとも、問い合わせフォームの送信がメールだったとすると…

外部から傍受される危険性が高くなります

とこの記事ではかかれていますが、そもそもHTTPHTTPS通信を傍受するより遥かに

メールを傍受したほうがラクとも考えられるはず。

CMSを使っている方を非難するわけではないが、

CMS機能に甘んじて、こういったベーシック問題に考えが及んでいないとすると、

WEB制作者としては、ちょっと配慮が足らなくはないですか?

とおもう。

P.S SSLということばはもうないよ。

記事に対するつっこみではないですが、

SSLということばは、とても古い言葉です。

便宜上みんな「SSL」といっているだけで、

正しくは「TLS」でっせ。

2011-02-27

http://anond.hatelabo.jp/20110226180732

うーんググっても結局よくわからなかった

HTMLソースになんか書いてあるよみたい増田の書き込みは

見つかったけど自分の書いたページのソース見ても特に何も見つからない

増田は書き込んだ瞬間に他の増田個人情報アクセスされる可能性がある

これ本当ですかね?セキュリティのことはよくわからないけどセッションハイジャックとか

そういう怖いあれが匿名ダイアリーにはあるんです

誰か教えてください

2010-04-04

http://anond.hatelabo.jp/20100404013718

そろってるっつーかなんつーか・・・

ログイン周りなんて、フレームワーク使わなくても、4時間かかるかどうかだよ・・・セッション周り慣れている人という前提なら。

 

問題なのはページ数が増えたときにすべてのページに間違いなく確実に同じ処理を入れることで

それが複数人のプログラマになっても、守られること。

そうなるとフレームワークの出番ってはなし。

あとは、それこそセッションハイジャックやらセキュリティ対策が時間がかかる。

 

今回問題なのは、そんな、慣れている人なら、そもそも、いわれなくても入っている。最初に入れておく一般的機能がまったくはいっていないこと。

robots.txtすらおかれていないこと。普通管理画面以下は、万一に備えて、robtos.txtを置く。という知識もないこと。

 

そして一番問題なのは PCソフト販売会社がその程度の、セキュリティー知識もない会社に発注するほど、セキュリティー知識がないこと。

コレだとすると、発注側にノウハウが無いので、今後も、セキュリティーの向上は見込めない。

 

こう言っちゃ何だが、ユーザー訴訟を起こすべきだし、PCソフト販売会社はさっさと、別なまともな会社に頼むか、

ショッピングカートなんて それこそ、実績のあるレンタルが他にもあるんだから、さっさと別会社に移行すべき。

2010-03-24

http://anond.hatelabo.jp/20100307173411

プロキシ犯人説でもいいんだが、相当強固にリクエストを無視するプロキシがあったとして、

セッションハイジャックができたらまずいんじゃねーか?

そういう企業プロキシが存在している事は周知の事実なんだから、楽天ほどの商業サイトで決済からんでるんだし

ログイン直後は302で1度飛ばすとか、ランダムセッションキーをURLのけつにつけるとか、Cache-Control ちゃんと入れるとか、複数の手を使ってプロキシキャッシュすり抜けようとしたあげく、

どうしても無理そうならjsランダムハッシュ付きURLから情報取得してセションと一致しないようならhttpsへ逃げるなど多重の手段を講じてもおかしくないだろ?

企業プロキシをすり抜けられなくて、セッションハイジャックです。でも、それはプロキシが悪いんですは、言いたいことはわかるが、決済系のWebサイトセリフじゃない。

コメント見る限り、他の企業プロキシからも同じ現象は再現しているみたいだし、プロキシーのCache-Control を無視する設定のプロキシ対策を忘れたんじゃなかろうか?というのに1票入れとく。

状況がわからんが、もし、Cache-Control を無視するプロキシー対策忘れなら、一般サイトならセーフだが、課金サイトなら、サイト側のマネージャークラス責任

ハイジャックは言い過ぎか、キャッシュピーピングのぞきみ)だな

2010-03-15

http://anond.hatelabo.jp/20100103122140

楽天 : メールアドレス流出騒ぎ 

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 

個人情報流出騒ぎ2005年

 

mixi : サン牧流出騒ぎ 画像流出騒ぎ

などがあるものの、基本的にmixi本体による騒動はなし。

パスワードも平文を送ってくるなどという事は無し

 

DeNA : http://www.security-next.com/004849.html

子会社顧客情報流出

モバゲー事態はセキュリティというよりも、青少年育成の観点から問題視される

 

はてな:有名どころではDoCoMoなどもモバイルURLをそのまま出したために

セッションハイジャックされた件などが記憶に新しい。

 

他、悪徳商法マニアクス関連でトラブル

セキュリティというより、法務周りでトラブルを抱える。

悪徳商法マニアクスが悪徳商法関連の記事を書いたところ、営業妨害としてはてなクレームをもらい

裁判の結果を待たずに削除。逆にはてなが訴えられる。

GREE:ウォッチしてないので、知らんw

 

いずれにしろ、mixi GREE DeNAなどは、いわゆる非技術者向けサービスのためにフィッシング詐欺が憂慮されるが、

あまり、フィッシング詐欺(マンインミドル含む)にたいして強固とは言えないのではないか?という疑惑はある。

 

Yahoo銀行はコレに対抗するためにセキュリティシールなどを導入している。が、やはり、マンインミドルにたいして

安全かどうかは疑問。

つか、銀行でも、行員による使い込みなどは、たまに起きるし、セキュリティーってなに?って気はする。

 

あと、某大手、キャリーアが提携していた大型サービスパスワード平文でおどろいた。

結構、古い大企業がやっているところはパスワード平文が目立つ気がする。

2009-08-03

インターネット常時接続なのに、セッション管理とはこれ如何に!?

おい、kawango!一般人にも感じがつかめるようにセッション管理について教えてやる

 

一般の人にとって一番わかりにくいのが

ということ。

「えー、うちのインターネット常時接続だよ?」とかいう奴は蓬莱弾幕でも食らっていやがれ。

 

インターネット接続方法を例え話にすると

となる。接続状態(太郎くんのお家にお邪魔している状態)というものは存在しない。とにかく毎回毎回、「ピンポーン」とやって、いちいち要件を伝えないといけない。ちなみに執事はいつも受動的。言われたことしかしない。

 

さて、もうちょっと高度に

ことも出来る。

好きな人はさすがに一部の友達にしか伝えられないので、山田家の執事は決められたルールに従って、「太郎の様子は万人に伝えても良いが、太郎の好きな人はマブダチにしか伝えてはならない」といった篩い分けをする必要がある。今僕らが話題にしたい「認証」の問題だ。

もちろん人間執事なら、一度覚えれば、誰がマブダチで誰がそうでないかはわかるわけだが、現実Webサーバー杓子定規なので、毎回毎回「名前ユーザー名)と合言葉パスワード)」を聞いて、本当にマブダチかどうかを確認する。

マブダチA:「太郎君の好きな人って誰? 僕は《マブダチA》、合言葉は《おニャン子》だよ」

執事:「初音ミクです」

マブダチA:「その前は誰だったの?」

執事:「お名前と合言葉をどうぞ」

マブダチA:「その前は誰だったの? 僕は《マブダチA》、合言葉は《おニャン子》だよ」

執事:「アララ・ミルクです」

という面倒な方法をとらないといけない。

 

要するにページを移動するたびに(ひとつまえの好きな人を聞くたびに)、認証(マブダチ確認)を行う必要がある。

それはめんどくさいから、ある一定期間の間は特殊な記号を使って、認証を楽に済ませましょうというのが、HTTPにおけるセッション管理だ。

さっきの例え話でいくと、

山田家の執事がマブダチAの手間を考えて「毎回お名前と合言葉を言ってもらうのも面倒ですから、このバッジセッションID)をお渡ししますので胸に付けてください(クッキーに保存)。それを見ればわかりますから。但し、最後のお問合せから30分以上すぎたらお名前と合言葉をもう一度言ってもらいます(セッションIDの有効期限)。そのときはまた新しいバッジをあげます」となる。

大事なことは、このバッジが一時的にしか使われないものということだ。どのくらいの期限を有効とするかはその家族で決めたルールによる。いずれにせよ、バッジがあれば完全スルーであるので気をつける必要がある。

 

要するにセッション管理を利用することで、実はマブダチじゃない人にマブダチを騙られるリスクが増すんだ。

毎回毎回、ユーザー名とパスワードを答えるのは面倒だから、バッジでよろしくね!ってなったら、バッジジャイアンに奪われたり、スネ夫盗み見られたり、出来杉君に気付かないうちに誘導させられたりというリスクが出てきてしまう。それを心配しないといけないんだ。

 

ここで、もしだよ、マブダチAが、世界自分だけが持っている変更不可能な情報バッジの代わりに使ったとしよう。例えばDNAだ。

執事DNAでマブダチかどうかを判断する。簡単ログインのためにあなたはDNA情報を提供しますか?となる。山田さんの家も、佐藤さんの家も、田中さんの家もDNA情報ひとつで認証を済んでしまうような社会だ。しかもマブダチAを表すDNAはひとつしかない。よって、このDNAを1つコピーするだけでマブダチAになりすませる。hatenamixiもNaviTimeもDNA認証を使っているサービスは全部だ。もちろん、このDNA認証を一般のセッション管理と同じように有効期限を設定して、その都度破棄することもできるが……。それはあくまで、善意執事の場合であって……。DNA情報と本人の個人情報マッチングして裏でほくそえむ黒執事がいたら……ざわっざわざわ……。

しかも、DNA情報暗号化せずによこせと言ってる奴もいるッ!な……何を言ってるのかわからねーと思うが、おれも何が目的なのかわからねえ……。オレオレ詐欺だとか、クレジットマスターだとか、そんなチャチなもんじゃねえ……。DNA情報ばら撒きというもっと恐ろしいものの片鱗を味わったぜ……。

 

わかったか、kawango!

ニコニコ技術者が即対応したからよかったんだぞ!

っていうか、指摘されるまで気が付かないという業界は恐ろしいぞ。業界ぐるみDNA情報を集めて利用しようって魂胆か?

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん