問題タブ [session-hijacking]

これは私の現在のセッション管理です:

IPアドレスの最初の3つの部分のみを使用する計画でIPの問題を変更することを認識しています。しかし、私が懸念しているのは、攻撃者がヘッダーなどを盗聴できることです。じゃあ守られないよね？私が被害者のネットワーク内の攻撃者である場合、1 つの応答ヘッダーを盗聴した後、簡単な GET 要求を行うだけで、再生成されたノンスを取得できます。これを防ぐ方法は本当にありますか？

多すぎなければ、自分のアプローチについて洞察を得たいと思っていました。これはどのように回避できますか？私は何か大きなものを見逃していますか？

クッキーとセッションの両方に長所と短所があります。しかし、ユーザーがログインすると、ユーザー名とパスワードを使用してセッションが作成されるのではないかと考えていましたが、登録すると、一意の「アクセストークン」が与えられます。

したがって、ログインすると、アクセストークンを含むCookieと、ユーザー名とパスワードを含むセッションが作成されます。

次に、データベースをスキャンして、セッションにユーザー名とパスワードがあり、Cookieにアクセストークンがあるユーザーを探します。

これにより、セッションハイジャックが防止されることを期待していました。

私は CakePHP の Cookie を理解しようとしており、少し変わった認証要件を満たしています。

現在 COTS ソフトウェアで構築されたレポート システムと統合されている CakePHP ベースのデータ収集システムがあります。レポート システムはアクセス制御する必要があり、両方のシステムですべてのユーザー アカウントを複製したくない場合を除き、CakePHP システムでユーザーが認証されているかどうかをレポート システムで確認できるようにする必要があります。

レポーティング システムでは、クライアントのレポート リクエストが最初に到着したときに、Java クラスをロードして機能を実行することができます。だから私の考えは

1. 着信レポート リクエストを検査し、CakePHP サイトで認証/セッション識別に使用される Cookie を抽出します。
2. この Cookie を添付して、Java 関数から CakePHP サイト内の「reportauth」アクションにリクエストを送信します。
3. その後、CakePHP 内の reportauth アクションは、ユーザーが CakePHP サイトにログインしているかどうかを確認し、暗号化された応答を Java 関数に返し、ユーザーの役割を識別します。

Cookie を取得してリクエストで送信し、暗号化された情報を PHP と Java の間で個別に共有できます。

ただし、Java リクエストで「フレッシュ」Cookie (新しいログイン後にブラウザが CakePHP サイトへのリクエストで繰り返し送信する Cookie) を使用すると、応答はユーザーがログインしていないことを示します。その後、ブラウザでサイトをリロードすると、ログアウトされました。ユーザー エージェント (?) に関する追加情報が Cookie に含まれている可能性があると思われます。これにより、Java ソースのリクエストがスローされ、そのセッションが安全のために破棄されますが、システムについてはよくわかりません。私は、CakePHP がセッションのハイジャックから保護しているのを見ているのではないかと思います (通常、これは私を喜ばせます)。

この問題を回避する方法があるかどうか、誰か教えてもらえますか? データ収集サイトはすでに稼働しており、レポートの締め切りも間近に迫っているため、CakePHP のカスタム認証コンポーネントを含まないサイトが望ましいです。

どんな助けでも大歓迎です。

重複の可能性：
PHPセッション固定/ハイジャック

私は$_SESSIONスーパーグローバルを頻繁に使用しています。

ただし、状況は次のようになります。

ユーザーがログに記録されたら、彼のID（MySQLテーブル）を追跡したいと思います。IDを簡単に挿入できます$_SESSION['id'] = $user_id;

結局のところ、私は自分のサイトのページ全体でその変数を使用できます。私の頭に浮かぶのは、ユーザーはIDをだまして別のIDにすることができるということです。単純な番号があることがわかったら、それを少し変更して何が起こるかを確認できます-データベース内のエントリの追加、削除、編集にユーザーIDが使用されるため、多くの問題が発生する可能性があるため、これを防ぎたいと思います。

session_regenerate_id()セッションをハイジャックから保護するのに十分ですか？

結論： Cookieはセッション識別子のみを保存します-すべての値はサーバー上にあり、クライアント側に渡されることはありません。 StackOverflowでのセッション固定/ハイジャックについて読む

セッション ハイジャックのしくみについて私が理解していることから、ASP.NET セッションにユーザー認証情報を保存するよりも、フォーム認証に利点があるとは思えません。フォーム認証と ASP.NET セッションは両方とも、整合性を検証するためにハッシュされた Cookie を使用しますが、どちらも Cookie を盗んでユーザーになりすますハッカーから保護することはできません。セキュリティに関する限り、ASP.NET セッションに認証情報を保存するよりもフォーム認証を使用する理由はありますか?

私はこのトピックがたくさん議論されていることを知っていますが、まだ答えられていないいくつかの特定の質問があります。例えば：

だから、私の質問は

• はini_set十分なセキュリティを提供しますか？
• ユーザーのIPとナビゲーターを保存し、ページが読み込まれるたびにそれをチェックして、セッションハイジャックを検出しても大丈夫ですか？これは何らかの問題がありますか？
• 使用はsession_regenerate_id()正しいですか？
• 使用はsession_id()正しいですか？

クレジットカード番号をデータベースに保存するトラフィックの少ないショップのWebサイトを維持しています。これは正しくない（または私が信じる合法でさえある）ので、番号の保存方法を変更しています。

サイトの構成方法では、クレジットカード情報ページがそれ自体に投稿し、データを検証し、データをデータベースに保存してから、ユーザーをcc検証ページにリダイレクトします。ここでccが検証され、注文が行われます。その後、注文完了ページに再度リダイレクトされます。とにかく、cc情報ページから検証ページにcc番号を取得するために、セッションを使用することを考えていましたが、脆弱性が心配で、それらを調べようとしています（私はこの参照とこれを読んでいます） 。cc番号をセッションに保存し、次のページで取得して使用すると、unset()数秒で消えます（これらのページはSSLを使用していることに注意してください）。何かのようなもの：

cc情報ページ：

cc検証ページ：

カード番号のみがセッションに保存され、残りのcc情報はデータベースに保存されます。誰かがcc＃だけで多くのことができるとは思いませんが、それでも可能な限り保護する必要があります。

と（セッション識別子はURLではなくCookiesession.use_trans_sid = 0をsession.use_only_cookies = 1介してのみ処理される（なぜ両方が必要なのかわからない））を使用し、この特定のセッション変数を使用すると、このコードはセッション固定に対して脆弱ですか？セッションIDを再生成することは有益でしょうか（後または前ですか？）sessionこの場合、cc＃を設定しましたか？はいと思います。この時点でプロトコルはSSLであるため、session再生成されると、SSLが取得できる限り保護されていると思います。

したがって、私の主な質問は、私のサイトでこれらのガイドラインに従うと、熟練した攻撃者は、セッションを修正/ハイジャックして、ユーザーのcc＃を存在する時間（約3〜15秒）取得するのにかなり困難な時間を費やすでしょうか？そうでない場合、可能であれば、どのようにしてその時点に到達できますか？

私の Web アプリが、自分の資格情報をアプリに提供するユーザーに代わって動作しているとします。これにより、アプリはサード パーティ サービスへの API 呼び出しを行うことができます。ちなみに、これはこのサードパーティのサイト (eBay に少し似ていますが、規模は小さい) に製品のオファーを投稿するためのものです。

この投稿を簡単にする非常に便利な方法の 1 つは、サードパーティ サービスが認証済みユーザー向けの製品オファーを受け入れる必要がある洗練された Web フォームを再利用することです。Web フォームに入力し、クライアント ブラウザーをリダイレクトして、ユーザーが洗練された使い慣れた Web フォームを使用して編集できるようにするという考え方です。これは最高のユーザー エクスペリエンスであり、実装作業は最小限ですみます。

ただし、文書化された方法ではありません。さらに、リクエスト パラメータ (GET または POST) からフォーム フィールドに入力するような単純な方法では機能しません。Webフォームはそのようには機能しません。

代替案があるかもしれません。私のアプリは、ユーザーに代わってサードパーティのアプリとのセッションを開き、すべてのデータを送信してデータベースに保存し、ユーザーのブラウザーに、サーバー アプリが開いたセッションを引き継ぐために必要なすべてのデータを送信できます。代理。これはまだ試していないことに注意してください。また、サードパーティのアプリがセッションを IP 番号に関連付けると、失敗する可能性があると思います (これは、健全かどうかに関係なく、アプリが行う可能性があります)。

しかし、HTTP セッションを開くサーバー プログラムに、そのセッションを引き継ぐために必要なすべての情報を HTML/Javascript ドキュメントに書き込み、そのドキュメントをユーザーのブラウザに送信させることはできないでしょうか。 HttpFox を使用して観察してきた、サードパーティのフォームでブラウザを直接使用したときに構成されたように?

すべての情報、つまりすべてが HTTP です。サーバーのIP番号をクライアントに渡すことは明らかに不可能です...しかし、すべてのCookieとパラメーター. ブラウザで実行されている Javascript は、サーバー アプリが開いたセッションに直接入るサード パーティの Web サイトへの要求を作成するために、何らかの方法でドキュメント (おそらくスクリプト部分) に渡す情報を使用する必要があります。 . これは、私のドメインから発信されたドキュメントが Cookie を設定 (リクエスト ヘッダーを追加) し、ユーザーのブラウザにそのリクエストを実行させることを意味します。

つまり、サーバーからクライアントにセッションを渡すことは技術的に可能ですか?

Javascriptでどのようにしますか？

アップデート

別の質問への回答によると、別のドメインに Cookie を設定することはできません。これを許可すると、重大なセキュリティ上の欠陥が発生します。私がフロントエンド開発者ではないことを示します。

まだ、あきらめていません。そこにXmlHttpRequestオブジェクトがあります。たぶん、これは私の邪悪な目的のために悪用される可能性がありますか?

2 回目の更新

ということで実験してみましXmlHttpRequestた。悪いニュース (私とこの特定のケースにとって): どちらを使用しても機能しないようです (現在の Firefox を使用して) 私の巧妙に偽造されたリクエストが、クロスオリジン リソースXmlHttpRequestの W3C 標準になる予定のものに従って書き直されているためです。共有しているため、Cookieヘッダーは単純に削除され、ダミーのヘッダーはMoinにGurke縮小されAccess-Control-Request-Headers: gurke,moinます。率直に言って、これはゲームを大きく台無しにしています。がっかりだよ。

Socket.IOを使用すると、Socket.IOサーバーへのJavaScript呼び出しを介して、他のクライアントが特定のアクティビティを実行したときにクライアントに通知されます。

そのメッセージはすべてのクライアントにブロードキャストされ、クライアント側のロジックが通知を表示するユーザーを決定します。（これに対する別のオプションは、サーバー上に関連するクライアントのコレクションを維持し、send()それらのクライアントのみに維持することです-より良いですか？）

誰かがコードを乗っ取ってサーバーに繰り返し通知を送信するのを防ぐために、システムはどのように構築されますか？（ある種のトークン化された送信？）誰かが合法的にログインし、そのセッションを使用してシステムをダウンさせようとする可能性があるため、単にセッションIDを使用するだけでは不十分です。

これにJavaScriptを使用する（クライアント側のハイジャックの可能性を回避する）のではなく、別のアプローチとして、SignalRを使用してコードビハインドシナリオから通知を送信することもできます。これについてはまだ調査中ですが、いくつかの議論/提案を歓迎します。