セッションハイジャックの対策方法について

質問

http://okwave.jp/qa5356018.html
上記の質問の便乗質問です

質問１
上記の質問内＃５で、セッションハイジャック対策として、
セッションIDとUserAegntを組みで管理しハイジャックリスクを軽減する
また、この方法を使用しているサイトも存在するとの記述がありますが、
セッションIDを盗聴出来る（つまりHTTPヘッダを読み取る）のであれば、必然的にUserAgentも盗聴されるので、この方法でハイジャックリスクを低減することは出来ないと思うのですが、いかがでしょうか？
そもそも、私のDoCoMoの携帯はUserAgentを送らないし・・・

質問２
同じく＃５で
「IPアドレスチェックはセッションハイジャック対策にならない」
とありますが、たしかに携帯等からアクセスするとIPが著しく変化する可能性がありますが、無限に変化するわけではありません
しょせん、携帯会社が保有するIPの範囲内です
たとえばDoCoMoであれば、IPのホストアドレスの数はたかただか４，５種類です
よって、「IPアドレスのホストアドレスをチェックすることで送信元を限定」し、ハイジャックチェックをすることは可能だと思うのですがいかがでしょう？
もちろん、DoCoMoネットワーク内部のハイジャッカーには対応できませんが、簡単に偽装可能なUserAgent（たとえば、FirefoxはUserAgentを変更する項目がある）でチェックするよりはるかに有効だと思います

携帯以外で企業内部からProxy経由で接続してきた場合、これもIPアドレスが変化する可能性があるようですが、企業も無限にIPを保有しているわけではなく、特定のホストアドレス内の範囲のはずです
よって、同一セッションIDの接続でIPが変化した場合、ホストアドレス上位２４bitまたは16bitが変化したかで不正接続かどうかを判断できると思います
もちろん、同一企業内にハイジャッカーが居たら上記の方法では判別できませんが、企業内のセキュリティ不備までホームページ提供者（セッションIDを提供する側）が考慮してあげる必要は無いと思っています

また、IPアドレスの変化量に応じてセッションIDのライフタイムを減らし、リスクを低減するような機能もついでに追加しても有効ではないでしょうか？
つまり、IPが変化するネットワークからのアクセスは、リスク軽減のためセッションIDのライフタイムをデフォルト30分を15分に減らすなど。

また、IPアドレスに変化がない場合は、当然上記のチェックはする必要はなく、クライアントを信用します

このような方法でセッションハイジャック対応（もちろん１００％ではないが、かなり有効だと思う）出来そうですが、
いかがでしょうか？
また、このような方法でチェックしているサイトはありますでしょうか？

回答No.5

Lchan0211

> 質問1
通信電文の盗聴を前提としたセッションハイジャックの対策としては、
UserAgentを使うのは確かにあまり意味がないと思います。
ただ、前回の回答5さんの記述をよく読むと、、UserAgentが
セッションハイジャック対策に有効であるとは一言も言ってなく、
同一接続者の可能性を示す一つの手掛かりとして、UserAgentを
紹介しているにすぎないと思います。

>質問2
私も、そのようにIPアドレス情報を工夫してチェックすることは、
セッションハイジャック対策に有効な場面があると思います。

ただ、以下のようなケースを想定した場合、IPアドレスのチェックが
全く有効にならないことも、認識しておくべきと思います。
(知識があれば誰でもできるので、結構ありがちだと思います。)

・アパート内のある住人の善意から、その住人の無線LANを利用させてもらっている。
・駅前に、フリーで使える無線LANのESSIDがあった。自分のPCはウィルスチェックソフトや
ファイアーウォールでガードしているから大丈夫と思い、ブラウザだけ利用。
↓
これらの無線LAN(NATルータ)管理者が実は悪人で、
パケットキャプチャして、セッションハイジャック
↓
NAT構成で、正規ユーザと同じIPでセッション接続できるため、
IPアドレスによるチェックは全く役に立たない。
ユーザエージェントが異っていることをチェックすれば
ガードされる可能性もあるが、ユーザエージェントも偽装すれば
すり抜け可能。ただ、そのサーバがどのような情報をセッションチェックに
利用しているかは、最初から攻撃者にはわからないので、
これにより多少は時間が稼げるかもしれない。
その間にセッションIDの再払い出しが行われればセーフ・・

それって、コンピュータのセキュリティに無頓着な素人ユーザの自己責任じゃ?
と考える人もいるかもしれませんが、こんなことを意識しなくても
安全に使えるシステムがあるべき姿ですね。

お礼

返答ありがとうございます
＞セッションハイジャック対策に有効であるとは一言も言ってなく、
いやいや、​http://okwave.jp/qa5356018.html
は、セッションハイジャックの対策としてIP管理での方法を質問しています
それに対しての回答でセッションIDとUserAgentで判断する方法を述べているわけなので、セッションハイジャック対策への対応の1手法として回答していますよ

＞これらの無線LAN(NATルータ)管理者が実は悪人で、
＞パケットキャプチャして、セッションハイジャック
この手法が、質問で上げたIPチェック方式の唯一の穴かなと考えています
ですから、この穴をふさぐために、
さらに、1通信毎にランダムなIDをサーバから振り出し、次のクライアントからのリクエストにはこのランダムなIDを必ず送信してもらう方法も同時に行ったらどうでしょうか？
パケットキャプチャして正規ユーザに成りすまして通信が成功した場合、
ハイジャッカーが一時的に通信成功しても、正規ユーザが通信を再開したら、正規ユーザの端末が保持しているIDがサーバと異なるため、ハイジャックが発生したと判断し、セッションIDを無効とし再ログインを促します

あと、いろいろ返答している中で思ったのですが、
セッションハイジャックは＃５の回答内にあるように、同一セグメント内の端末のセッションを盗聴するケースが最も高いような気がします
そうしますと、IPチェック方式もあまり有効ではないのかな。
結局、ハイジャックの対応なんていちいちやっててもしょうがないのかな？
現在、ハイジャック対応をしているサイトはいくつもあると思いますが、
「最近のセキュリティという言葉に脊髄反射して」無駄にコストかけていることになるのかなと考えてしまいます

回答No.4

wildcat-yp

＃１です。
私はIPアドレスも偽装可能と書いたつもりなのですが・・・
携帯専用ページ等でキャリアからの接続しかできない仕様であればほぼ不可能ですが、一般的にインターネットを通ってきた物であればIPアドレスもそれほど信用できるものではありません。とくに海外経由の通信の場合は。

なので、SSLが全ページへの適用が不可能という場合、SSL以外のコンテンツについては漏えいは覚悟するべきです。

確かにセッションハイジャックの対策としていろいろと設定を厳しくして、ハイジャックの難易度を上げることは常に必要ですが、かといって、暗号化していない通信に重要な情報を載せて良い理由にはなりません。

大事なところ以外はハイジャックされても大丈夫な作りにするか、後は多少お金をかけてでもSSL化するかだと思います。
SSLはそれほどサーバー負荷は高くないと思いますし、そんなに負荷がかかるほどのアクセス数があるのであればアクセラレータを入れても十分元がとれるシステムだと思うのですが・・・

DBに比べて、WEBサーバなんて数ランク性能を下げても十分だと思います。まさか、WEBとDBが同じサーバーということはありませんよね？

補足

返答ありがとうございます

＞私はIPアドレスも偽装可能と書いたつもりなのですが・・・
偽装可能とのことですので、質問の方法はまったくセキュリティ向上の意味を成さないと判断されたということですね？

＞一般的にインターネットを通ってきた物であればIPアドレスもそれほど信用できるものではありません。とくに海外経由の通信の場合は。
この件ですが、なぜ正規のユーザが海外Proxyを経由して匿名でサービスを受ける必要があるのでしょうか？
また、こんな回りくどい方法で接続する正規のユーザがどれほどいるのでしょうか？
この回答は正規のユーザがProxyを経由して偽装する可能性があるからIPチェックは無意味と取れるのですが・・・
また、ハイジャッカーが偽装のために海外PorxyのIPを埋め込んで（あるいは海外Proxy経由して）データ送信してきても、
正規ユーザはこの匿名Proxyを利用していないはずなので、IPアドレスチェックでIPアドレス不一致となり偽装は簡単に見破れると思いますが。

次に、「IPアドレスも偽装可能」の件ですが、
CGIで読み取れるREMOTE_ADDRはHTTPヘッダに含まれているわけではなく、
IPパケットのIPヘッダ内の送信元IPアドレスです
よって、単にIPヘッダの送信元IPアドレスを置き換えるだけでは偽装は出来ません
なぜならば、IPパケットにはシーケンス番号があり、この番号通りにパケットの送受信がされなければならないからです
単にIPヘッダだけをすりかえてもシーケンスが連続していないため、サーバ側のOSがパケットを破棄します
また、ハイジャッカーがIP偽装するとしたら、正規のユーザのIPアドレスで偽装することになると思いますが、この場合、サーバからの返信パケットはハイジャッカーの端末に送られず、正規のユーザの端末に送られることになりハイジャック失敗に終わると思いますが。

＞確かにセッションハイジャックの対策としていろいろ・・・
これは、質問の趣旨から外れています
セキュリティ向上のためにSSLがどれほど効果があるかをお聞きしているわけでは有りません
SSLが有効であることは存じておりますし、全てのページをSSL通信にしてしまうことがとても有効であることも存じております

＞大事なところ以外はハイジャックされても大丈夫な作りにするか
この方法の一つとして、IPアドレスチェックの有効性について質問させていただいているのですが・・・

＞DBに比べて、WEBサーバなんて数ランク性能を下げても十分だと思います。まさか、WEBとDBが同じサーバーということはありませんよね？
私はwebショッピングサイト等の運営は一切しておりません
今回の質問はセッションハイジャックを防ぐ一つの方法として有効か、この方式の理論を問うております

回答No.3

pokapoka1980

SSLは、SSLアクセラレータで対応するというのが一般的だというのをどこかで読んだ記憶があります。
何か対応してるロードバランサやPCIカードとかの宣伝だったかもしれませんが・・・。

使ったことは無いので、参考までに。

間違っていたらごめんなさい。

お礼

回答ありがとうございます
SSLアクセラレータの存在は知っています

質問の意図からそれてきているので、
修正させていただきますが、
SSLの実装方法や、情報漏えいに対するSSLの有効性を質問させていただいているわけでは有りません

先の回答でも返答させていただきましたが、
SSLをすべてのページに使用すれば、情報漏えいを殆ど回避できる可能性があるので、質問自体無意味ととれる回答は質問の趣旨に外れます

回答No.2

pokapoka1980

私もSSLが手っ取り早いと思います。
まあ、サーバで処理すると重くはなりますが・・。

それと、セッションハイジャックの可能性のほうが気になります。
国内の携帯から送信された情報が、サーバにたどり着くまでの経路上に盗み見れる地点があるとしたら、

１．携帯から飛んでる電波を捕まえる
２．携帯業者、AS、ISPの内部のルータやゲートウェイを監視or経路操作する
３．IDCのルータを監視or経路操作する

くらいでしょうか・・。
確率的にどれもものすごく低い気がします。

間違っていたらすみません。

お礼

回答ありがとうございます
質問にSSLを記述していませんでしたが、
回答＃１のお礼に記載したとおりです

「セッションハイジャックの可能性はものすごく低いから気にするな」とのことですが、
この低確率の現象が発生した場合、サーバ側での偽装の見破り方の一手法として、使えないか？と質問させていただきました
確率が低いから質問自体が無意味であるといわれてしまうと、
返答のしようもありません・・・

回答No.1

wildcat-yp

そんなにめんどくさいことをしても結局セッションハイジャックの危険度はたいして変わらないと思いますよ。

その気になれば偽装可能ですから。

普通はきちんと対策したいのであればSSLを入れます。
それだけで基本的には解決です。

お礼

回答ありがとうございます
質問に記述し忘れましたが、
ログイン、決済画面等ではSSLは利用する前提での話です
（SSLを使用しなければ、セッションを盗聴せずとも、ログインID/パスワードを盗聴してしまえば済む話ですから）
しかし、SSL画面から同一ドメイン内のhttpプロトコルのページ（たとえばトップページ）へ遷移した場合、SSLを使用しないので、セッションIDは平文で通信されてしまいます
じゃあ、すべてのページでSSLを利用すれば？となりますが、サーバ負荷がかかりすぎて利用できない前提です
このパターンは現在のwebショッピングでもっとも多い通信パターンだと思います

＞その気になれば偽装可能ですから。
今回の質問はこの偽装を見破る手段として、IPアドレスのチェックを質問させていただいていますので、
偽装できるかできないかを焦点にしているわけではありません
セッションハイジャックを100％防ぐことは無理だと考えています。しかし、可能な限り防ぐ手法（偽装を見破る手法）として質問の手法は、有効か検討させていただきたく質問させていただきました

この質問は、
http://okwave.jp/qa5354478.html
上記の質問の延長でもあります