2

これが私の質問の簡単なバージョンです：

Cookie が別のサーバー (この場合は Exchange メール サーバー) で使用される場合、何らかの方法でクライアントのブラウザーに Cookie を設定することは可能ですか? このシナリオでは、Cookie を設定しようとしているサーバーは "intranet.myschool.edu" にあり、交換サーバーは "owa_server.myschool.edu" にあります。


完全な質問は次のとおりです。

cURL を使用して、フォーム ベース認証が有効になっている Exchange サーバーに HTTP POST を送信する php スクリプトがあります。

HTTP POST (投稿された URL にユーザー/パスを含む) を成功させると、Exchange Server (具体的にはhttps://my.school.edu/exchweb/bin/auth/owaauth.dllファイル)クッキーを出力します。具体的には、「sessionid」と「cadata」id を出力します。

これらの Cookie ID がサーバー上のテキスト ファイルに書き込まれると、cURL/PHP はそれを参照し、Exchange/OWA サーバーから (webdav などを介して) データを要求できます。

その部分は機能します。私が解決したい問題は、Cookie ID をクライアントのブラウザーに渡すことです。これにより、クライアントはこれらの Cookie ID を使用して自分の OWA アカウントに自動ログインできるようになります。

本質的には、ユーザーが Active Directory ID を使用してイントラネットにログインし、最近の電子メールのスナップショットを確認できるようにしたいと考えています。その後、必要に応じて、完全な OWA Web アプリケーションに切り替えるための小さなリンクを提供します。この切り替えが発生した場合、OWA に手動でログインする必要はありません。彼らはすでに Active Directory のユーザー名とパスワードをイントラネットの前に提出しているので、OWA に自動ログインしてもらいたいのです。

Mac OS、Windows、および Linux が混在しているため、Windows 認証を使用してシングル サインオンを試みることはできないことに注意してください。

「setcookie」を実行して、cURL が取得した Cookie ID を割り当て、クライアントのブラウザーに入れることができると考えていました。

これは不可能ですか？この方法で Exchange/OWA (またはその他のサイト) を「偽装」することはできませんか? cURL がキャプチャした正当な Cookie ID があります。これらを別のコンピューターのクライアント ブラウザーに渡す方法はありませんか?

最悪の場合、Javascript を使用してユーザー名とパスワードを OWA ログイン ページに自動貼り付けすることが唯一の望みでしょうか? Exchange/OWA での二重ログインの問題を回避する方法について、他に考えがある人はいますか?

助けてくれてありがとう！

4

7 に答える 7

5

RFC 2965から(NB HDN = "ホスト ドメイン名)

ホスト A の名前がホスト B のドメインと一致する場合

  *  their host name strings string-compare equal; or

  * A is a HDN string and has the form NB, where N is a non-empty
     name string, B has the form .B', and B' is a HDN string.  (So,
     x.y.com domain-matches .Y.com but not Y.com.)

domain-match は可換演算ではないことに注意してください: abccom
domain-matches .c.com ですが、その逆ではありません。

したがって.myschool.edu、ドメインとして使用すると機能するはずです。注意してください。不可欠です

于 2009-01-29T22:18:20.880 に答える
3

「.myschool.edu」のドメイン部分で Cookie を設定できる場合があります。理論的には、「myschool.edu」のサブドメインでホストされている他のサイトに送信されます。

ただし、実際には、クライアント ソフトウェアが Cookie の範囲が広すぎると判断し、Cookie の返送を拒否する場合があります。

于 2009-01-29T22:12:21.983 に答える
1

可能であれば、これは深刻なセキュリティの抜け穴になると思います...

于 2009-01-29T22:05:17.037 に答える
1

このシナリオでは、Cookie を設定しようとしているサーバーは "intranet.myschool.edu" にあり、交換サーバーは "owa_server.myschool.edu" にあります。

あなたはそれができるはずです。

私は自分のサイトでこれを行います（例のために名前を変更します）：

URLにWebアプリがあります

webapp.domain.com

ユーザーがログインすると、次の場所にある PunBB フォーラム パッケージの Cookie を設定します。

フォーラム.ドメイン.com

PunBB フォーラム Cookie を設定/クリアすることで、便利なようにフォーラム アカウントでユーザーを自動的にログイン/ログアウトできます (もちろん、これは登録が同期されていることを前提としています。私の場合は、フォーラム登録を削除し、メイン サイトの登録によってフォーラムが作成されます)。ユーザーのアカウント)。

サブドメイン#1 で Cookie パスを「/」 (デフォルト) に設定し、Cookie ドメインを「domain.com」に設定するだけです。次に、サブドメイン #2 のアプリに Cookie が表示されます。

編集: barrowcが回答したのを見ました。いくつかの例で「.domain.com」パターンを見ました。私のサイトでは Cookie ドメインに「domain.com」を使用しており、それも機能します (欠落している場合は、php set_cookie が先頭のドットを追加する可能性があります)。 ?)

于 2009-01-29T23:39:09.080 に答える
0

私たちはこれを何ヶ月も懸命に戦ってきました。私たちが思いつくことができる最善の方法は、WebサーバーがすべてのログインでExchangeのCookieを取得できるようにすることです。問題は、Cookieアフィニティがないと、Webサーバーによって取得されたCookieが、クライアントが接続しているのと同じ負荷分散ノードからのものであることを確認する方法がないことです。

于 2009-11-06T19:46:50.350 に答える
0

iframe を使用して Cookie を設定できます。必要なCookie 変数を get または post 変数として設定して、Exchange http サーバー ( https://my.school.edu/exchweb/ )上のページにリクエストを行う Web サーバーに iframe を用意します。次に、vars を使用してそのドメインの Cookie を設定し、ユーザーを Exchange サーバーにリダイレクトします。

現在、OWA のバックエンドに、IP アドレス、ユーザー エージェントなどをチェックするロジックが存在する可能性があります。これを無効にする可能性のあるセッションを登録するときに、確認できません。

于 2009-01-31T04:36:36.170 に答える
0

ブラウザがそれを決定します...しかし、通常はできません。これは、一種の XSS 脆弱性と見なされます。

于 2009-01-29T22:47:32.240 に答える