問題タブ [session-fixation]

私はセッション固定について読みました、そしてそれがユーザーに攻撃者のセッションを使用することを強制することを私が理解していることから。これは正しいです？これがどのようにユーザーを怒らせる可能性があるかの例を教えてください。

ASP.NET MVC 1.0 には、クロス サイト リクエスト フォージェリのセキュリティ問題を処理するための新しい機能があります。

新しいフォームがレンダリングされるたびに、html フォームで生成されたトークンが変化し続けることがわかりました。

これらのトークンがどのように生成されるか知りたいですか? また、何らかのソフトウェアを使用してこのサイトをスキャンすると、別のセキュリティ上の問題が報告されます: セッションが修正されました。なんで？トークンが変更されているため、この問題はどのように発生するのでしょうか?

もう 1 つの関数があります。それは の「salt」ですがantiForgeryToken、トークンの生成に「salt」を使用しなくても、これが何に使用されるかはよくわかっています。トークンは常に変化します。関数？

ユーザーのユーザー名とパスワードを Cookie に保存することは良い方法ですか? ( Facebook、digg、twitterなどの) 大きな Web サイトがこれをどのように処理しているか知りたいです。私のコードはそのようなものです：

ログインが成功するたびに、$usernameと$password(md5) を Cookie に保存します。そして、セッションIDを再生成しますsession_regenerate_id()

ユーザーを認証するために、ログインセッションが存在するかどうかを確認し、そうでない場合はCookieを認証します。

何か案は？ありがとう

Webアプリがセッション固定に対して脆弱でないことを確認するために統合テストを作成しています。

認証ロジックで実際に起動していることを手動で確認しreset_sessionました。さらに、WebブラウザでログインするとCookieが実際に変更されることを確認しました（したがって、セッション固定に対して脆弱ではなくなりました）が、これを正常に検証するためのRSpec統合テスト。

これが私のRSpec統合テストです。

最後のアサートを除いて、すべてが機能します。クッキーは変更されません。

RSpec / Rails統合テストでreset_session期待どおりに機能しない既知の問題はありますか？セッション固定が問題ではないことを確認するテストを作成するにはどうすればよいですか？

現在、これを開発環境に実装しています。

• ログイン時に $SERVER['REMOTE_ADDR'] をセッション変数として保存し、同じ IP アドレスのページが読み込まれるたびにページを再チェックします。

読めば読むほど、多くの人がプロキシなどの理由でこのアイデアを好まないことがわかります...では、まだ良い練習になる可能性のある他のオプションは何ですか? 私は USER AGENT について考えていましたが、簡単な Firefox プラグインを使用すれば、どのジョーブローでもそれを偽装できます。とはいえ、攻撃者が最初の試行で正しいものを正しく選択するには、少なくとも適切な推測が必要です...

人々はどう思いますか？テキスト「SERVER_ADDR」を別のものに変更したいだけです。他のすべてのコードはそのままでかまいません。

ありがとう。

編集： ここでの私の主な目標は、ハイジャック/固定を防ぐことだと思います。IPチェックは、理論的には、ユーザーが常にユーザーのままであることを保証します（誰かがIPをスプーフィングしていない限り...）-しかし、セッションは基本的にこの邸宅のIPアドレスに保存されます...

セッションの固定を避けるために、こちらのようにコマンド「reset_session」を使用しています。

コマンドを実行した後、新しく生成された session_id をデータベースに保存したいのですが、session[:session_id] が定義されていません。

簡単なテストを書きました：

2 つの conescutives ページの読み込みのログの結果は次のとおりです。

と

ご覧のとおり、乱数 (172) は 2 番目のページに適切に渡されますが、新しいセッションには新しいセッション ID が表示されません。

「after_filter」の後に新しいセッション ID (「54f46f520c80044a9f5475af78a05502」) が生成されると思いますが、取得方法がわかりません。

セッション固定/ハイジャックのリスクについて SO に関する多くの Q/A を読み、多くの人が to などのディレクティブや他の php.ini ディレクティブを変更して、サーバーをより安全にすることを提案してphp.iniいます...session.use_only_cookiesON

• PHPでセッション固定を修正するにはどうすればよいですか
• PHP セッションの固定化 / ハイジャック

PHP5 + Apache ベースのローカルホスト サーバーで単純な攻撃シナリオを再現できるかどうか、この目で確かめたかったのです。

私のローカルホストsession.use_only_cookiesではOFF、上記のq/aによると、私のローカルホストは基本的に保護されていないため、テストを行う必要があります。

セッション固定攻撃がどのように実行されるかについて、この簡単な記事を最初に読みました。

• http://en.wikipedia.org/wiki/Session_fixation#A_simple_attack_scenario

この記事で説明したシナリオを再現するために、2 つの非常に単純な PHP スクリプトを作成しました (コードは以下にあります) が、攻撃は機能しません。

1. (マロリーのふりをして) 私はアリスに言います: 「こんにちは、http://localhost/login.php?PHPSESSID=mysessionidにアクセスしてください」</p>

2. それから (アリスのふりをして) http://localhost/login.php?PHPSESSID=mysessionidに行きました

3. 私のローカルホスト サーバーの管理者として、セッションがサーバー ディスク上に作成されているのを見た (それは という名前のファイルとして作成されているsess_ mysessionid) ので、私は思った: かっこいい、動いている!!!

4. 次に (アリスのふりをして) 資格情報として「joe」と入力してログインしました

5. アリスがログインすると、彼女は にリダイレクトさinsession_ok.phpれます。この時点で (上記のウィキペディアの記事によると)、マロリーはセッションを に固定しているため、マロリーも見ることができるはずですがinsession_ok.php、これは正しくありません。アリスが新しいセッションにログインすると、 serverで作成されたので、記事で説明されているように、マロリーがどのようにセッションを固定/ハイジャックすることになっているのか、この時点では理解できませんか???mysessionidsess_vdshg238cnfb4vt7ahpnp1p522

login.php

insession_ok.php

手がかり/アイデアはいつでも大歓迎です！

この仕様に従って OAuth 1.0 プロバイダーを実装しました。これは最新のはずです。仕様は、2009 年に確認されたセッション固定攻撃に対処するために修正されました。問題は、2 つの仕様を比較する必要があることを除けば、この問題に対応して仕様でどのような対策が追加/変更されたのかわかりません。

「正しい」仕様を実装したので、リスクを軽減するためにどのような手段を講じたかを利害関係者に説明するのに苦労しています。

誰かが私のために問題に光を当てたいと思っていますか?

期末レポートのセッションを複製しようとしています。ここでかなりのヒントを見つけましたが、ローカルホストへの攻撃を複製できません。

ここから例を試してみました: http://www.devshed.com/c/a/PHP/Sessions-and-Cookies/2/

fixation.php:

test.php

記事には、次のセッションを固定できるはずだと書かれています。

しかし、リクエストヘッダーを調べると、うまくいかないようです:

また、tmpフォルダに「sess_0avpo8ttlmg35apkjaovj6dgd3」というファイルがあります。

私はここでちょっと迷っており、うまくいかなかった同様の例をいくつか試しました...

これらの値を設定して、php.ini を少し更新します。

コメントアウトするとsession.save_handler、Cookie へのセッションの保存と tmp ファイルの生成が無効になります (間違っている場合は修正してください)。これで、セッションを固定し (sess_1234 という名前の tmp フォルダーにファイルがあります)、それもハイジャックできます (別のブラウザーで開き、状態を再開します)。繰り返しますが、私が間違っている場合は訂正してください-最近のphpバージョンでセッション固定化が完全にパッチされたのでしょうか、それともこの単純な攻撃でしょうか? 現在のバージョンは 5.3.4 です

私はJavaで書かれたWebアプリケーションを持っています。認証プロセスではセッションを使用しません。アプリケーション スキャンが実行され、セッション固定攻撃の可能性があることが判明しました。セッションを使用していないときに疑問に思っています。セッションの固定をどのように修正または防止しますか? これはFORTIFYスキャンレポートが伝えるものです