2011-05-10 18 views
6

私はセッション固定/ハイジャックの危険性について多くの人が読むとphp.iniの指示をsession.use_only_cookiesONなどのphp.iniディレクティブに変更することを提案していますより安全な...テスト用ローカルホストに対する簡単なセッション固定攻撃

私は、単純な攻撃シナリオを複製することができれば、私の目で見てみたかったです私のlocalhostサーバー上でPHP5 + Apacheに基づいています。

私のlocalhost session.use_only_cookiesOFFです。上記のq/aより、私のlocalhostは基本的に保護されていません。これはテストを行うためのものです。記事で説明するシナリオを再現するためには

が、私は2つの非常に単純なPHPスクリプトを作成しました:

私の第一は、セッション固定攻撃を施行している方法については、この簡単な記事を読んで(コードは以下の通りです)、しかし、攻撃は動作しません、これは私がやったことです:

  1. (マロリーするふり)私が言いますアリス:私は、サーバーのディスク上に作成されたセッションは、(それがファイルとしてセレイテッド型だ見た私のローカルホストサーバーの管理者としてhttp://localhost/login.php?PHPSESSID=mysessionid

  2. に行ってきましたそして、

  3. (アリスを装って)「ハローhttp://localhost/login.php?PHPSESSID=mysessionidを訪問しに行きます」 sess_ mysessionidという名前)ので、私は思った:クール、それは働いている!

  4. その後(アリスを装って)私は資格

  5. アリスがログインすると、彼女はinsession_ok.phpにリダイレクトされ、この時点で(上記のWikipediaの記事による)として「ジョー」を入力してログインしマロリー必要があります彼がセッションをmysessionidに固定したので、insession_ok.phpも見ることができますが、これは真実ではありません。新しいセッションがサーバーsess_vdshg238cnfb4vt7ahpnp1p522に作成されるため、Malloryが固定する記事で説明されているように、セッションをハイジャックする任意

    <?php 
    session_start(); 
    if(@$_SESSION['in_session'] === TRUE) 
        echo "in session ok"; 
    else //user is not in session cause he did not login, let's redirect him to login page 
    { 
        $webpage = 'http://' . $_SERVER['HTTP_HOST'] . '/login.php';  
        header("Location: " . $webpage, TRUE, 302); 
    } 
    ?> 
    

    insession_ok.php


login.php

<?php 
session_start(); 

//if user credentials are ok, let's put him in session 
if(@$_POST['usr'] === 'joe') 
    $_SESSION['in_session'] = TRUE; 

//if user is already logged in, let's redirect him to the account page "insession_ok.php" 
if(isset($_SESSION['in_session'])) 
{ 
    $webpage = 'http://' . $_SERVER['HTTP_HOST'] . '/insession_ok.php';  
    header("Location: " . $webpage, TRUE, 302); 
}  
?> 
<form method="POST" action="login.php"> 
    <input name="usr" type="text"> 
    <input type="submit" value="Submit"> 
</form>  
<script type="text/javascript"> 
    alert(document.cookie); //to view cookies 
</script> 

手掛かり/アイデアは常に高く評価されています!

答えて

6

これはセッション固定攻撃のテストに私が常に使用してきた方法です。それはHTTPプロトコルの知識が必要ですが、セッションの固定を見るのに十分なのであれば、HTTPのほんの少しだけあなたを恐れるべきではありません:

私が見ているセッション固定のバージョンここでは公共のコンピュータの考え方です。あなたは図書館に行き、www.myawesomesite.comのようなサイトに移動し、ログインせずにあなたに割り当てられたセッションIDを書き留めます。

その後、誰かがwww.myawesomesite.comにログインするのを待ちます。ログインするとすぐに、コンピュータのセッションをパブリックコンピュータで使用されたクッキーに手動で変更します。サーバーはあなたが認証されたユーザーだと考えます。

これをローカルホストでテストするには、ブラウザが通常Cookieを共有しないため、2つの異なるブラウザを使用してエフェクトを表示できます。ここで

はそれを行うための手順は次のとおりです。

  • 開き、Chromeとlocalhostに移動します。これは公共のコンピュータを表します。セッションIDを調べて書き留めます。これを行うには、Fiddlerのようなプログラムを使用してリクエストを表示するか、Web Developerのようなプラグインを使用してCookieを表示します。 Cookieの値は次のようになりますPHPSESSID=46l11p0vt81ouo2hkt0ck8ij76

  • Firefoxを開き、localhostに移動します。これは攻撃者のコンピュータを表します。 Web Developerプラグインを使用して、PHPSESSID CookieをChromeから書き留めた値に変更します。

  • Chromeでは、Aliceとしてログインします。これはログインしている犠牲者を表します。

  • Firefoxに戻るには、[最新の情報に更新]をクリックするか、認証専用のページに移動します。セッションの固定を受けやすい場合は、ログインをバイパスして、Alice on Firefoxとしてログインする必要があります。

この修正は簡単です(ご覧のとおりです)。ユーザーがコード内で認証するとすぐにsession_regenerate_id()に電話するだけです。これはログインに先立って使用されたセッションIDを無効にし、ログイン後(ただしログアウトする前に)OscarがセッションID を盗もうとする必要があることを意味します。

1

session.use_only_cookiesが無効になっていることを除けば、$_COOKIEよりも$_GETを好むので、有効なセッションIDクッキーが存在しないことを確認する必要があります。実際、ログイン後に別のセッションIDを持つアリスの原因は、おそらくアリスがURLを介して提供されたセッションIDの代わりに使用されるセッションIDを持つ有効なクッキーを持っているためです。また、クッキーを無効にして、session.use_trans_sidがクッキーをまったく使わないようにすることもできます。

あなたの攻撃は、期待どおりに機能するはずです。

関連する問題