64

ユーザーをチェックアウト ページに送ると、 からhttp://sitename.comに切り替わりhttps://sitename.comます。

その結果、$_SESSION変数が失われます。

このサイトには有効な SSL 証明書がありますが、これは役立つ場合とそうでない場合があります。

4

16 に答える 16

71

同じサーバーで HTTP サービスと HTTPS サービスを切り替えると、HTTP セッション ID が HTTPS セッションに渡されません。次の 3 つの方法のいずれかで、HTTP ページから HTTPS ページにセッション ID を渡すことで設定できます。

PHPから: session_start :

session_start()GET、POST、Cookie などのリクエストを介して渡される現在のセッション ID に基づいて、セッションを作成するか、現在のセッションを再開します

セッションを使用しているときは、通常、スクリプトを で開始しますsession_start()。ブラウザにセッション ID Cookie が設定されている場合は、session_start()そのセッション ID が使用されます。ブラウザにセッション ID Cookie が設定されていない場合はsession_start()、新しい Cookie が作成されます。

セッション ID が設定されていない場合 (この例では、ブラウザが HTTPS セッション用の新しいセッション ID Cookie を作成しています)、session_id()関数を使用して設定できます。session_id()また、便利なようにセッション ID を文字列として返します。そう

...

$currentSessionID = session_id();

...

$currentSessionID変数を現在のセッション ID に設定し、

...

session_id($aSessionID);

...

ブラウザの sessionID Cookie を に設定し$aSessionIDます。PHPから: session_id

2 つのスクリプトを使用した例を次に示します。1 つは HTTP 経由でアクセスされ、もう 1 つは HTTPS 経由でアクセスされます。セッション データを維持するには、それらが同じサーバー上にある必要があります。

スクリプト 1 (HTTP) :

<?php

// This script will create a session and display a link to your secure server address
// to transfer your session ID. In this example, the secure page to receive the session
// ID is located at http://www.yoursite.com/safePages/securePage.php

// Start a session using the current session ID stored in a cookie, or create
// a new session if none is set.
session_start();

$currentSessionID = session_id();

// Set a variable that will be retrieved with the HTTPS script.
$_SESSION['testvariable'] = 'It worked';

// $secureServerDomain is the domain of your secure server
$secureServerDomain = 'www.yoursite.com';

// $securePagePath is the path to the page that will receive and set the session ID.
$securePagePath = '/safePages/securePage.php'

echo '<a href="https://' . $secureServerDomain . $securePagePath . '?session="' . $currentSessionID . '">Click here to transfer your session to the secure server</a>';

?>

スクリプト 2 (HTTPS) :

<?php

// Retrieve the session ID as passed via the GET method.
$currentSessionID = $_GET['session'];

// Set a cookie for the session ID.
session_id($currentSessionID);

// Start a session.
session_start();

// Test retrieval of variable set when using HTTP.
if (!empty($_SESSION['testvariable'])) {
      echo $_SESSION['testvariable'];
} else {
      echo 'It did not work.';
}

?>

これを機能させるには、HTTP サーバーと HTTPS サーバーが同じセッション データ ストレージ サブストレートを使用する必要があります (つまり、デフォルトのファイル ハンドラーの場合は、同じ物理マシンで同じ php.ini を使用して実行します)。ここにはセキュリティ上の欠陥がいくつかあるため、このコードを使用して機密情報を転送することはしません。これは、実行可能な例としてのみ使用されます。

以前にこの問題に遭遇したとき、簡単な修正として上記を思いつきましたが、問題の元の原因を思い出しただけです。http://www.example.com/page.phpからhttps://example.com/page.phpに移動していました (「www」がないことに注意してください)。http://www.example.com/page.phpがhttps://www.example.com/page.phpにリンクし、http://example.comがhttps://example.comにリンクしていることを確認してください。 /page.php .

PS、私は実際にこれらのスクリプトを実行していないので、そのままでは適切に実行できないタイプミスが 1 つまたは 2 つある可能性があります。

于 2009-01-14T03:06:10.490 に答える
16

セッション Cookie が安全に設定されているようです。Cookie には「安全な」フラグがあり、true に設定すると、Cookie が https 以外のサイトに送信されないことを意味します。PHP はおそらくそれをセッション Cookie に使用しています。これは、session_set_cookie_params関数、またはphp.iniのsession.cookie_secure設定で変更できます。

于 2009-01-14T03:15:18.617 に答える
12

この問題もありました。これは、PHP インストールでsuhosinパッチを使用していたためであることが判明しました。suhosin.session.cryptdocroot = Offに設定することで修正します/etc/php.d/suhosin.ini。

suhosin のマニュアルについては、http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptdocroot をsuhosin.session.cryptdocroot参照してください。

最初にこのブログ投稿から修正を見つけました。

于 2010-07-16T20:17:43.157 に答える
6

次のソリューションでは、セキュア サーバーと非セキュア サーバーが同じバックエンド サービス (キャッシュ、データベース ストアなど) にアクセスできることを前提としています。

買い物を終えたユーザーをチェックアウト フローに送る際にも、同じ問題に対処する必要がありました。これを解決するために、キャッシュ レイヤーを配置し、関連するすべてのデータをキャッシュしました。たとえば、セッション値から製品 ID とユーザー ID を収集し、それらをシリアル化し、ハッシュを作成し、最後にハッシュをキーとしてキャッシュ内にセッション データを保存します。次に、URL にハッシュを使用して、ユーザーを安全なサイトにリダイレクトします。

ユーザーが安全なサイトに到達すると、ハッシュに基づいてキャッシュからデータを取得しようとします。次に、ユーザー ID と製品 ID を使用して、価格と説明のすべてのデータをデータベースから読み込み、最終的なチェックアウト レビューのためにユーザーに提示します。

キャッシュ データは揮発性であるという継承のリスクがありますが、リダイレクトが迅速に行われるため、問題が発生したことはありません。

于 2011-11-15T20:43:56.030 に答える
1

HTTPからHTTPSまたはHTTPSからHTTPの間のセッションを管理できます。

  1. GETを使用してページ間でセッションIDを送信する

  2. POSTによるPOSTセッションID

  3. ファイルを使用してセッションを保存する

  4. セッションにCookieを使用する

  5. データベースを使用してセッションを保存する

以下の例は、GET…を使用して送信するために使用できます。

ファイル：http.php……………</ p> 

<?php

session_start();

$sessionID = session_id();

$_SESSION['demo'] = ‘Demo session between HTTP HTTPS’;

echo ‘&lt;a href=”https://www.svnlabs.com/https.php?session=’.$sessionID.’”&gt;Demo session from HTTP to HTTPS</a>’;

?>

ファイル：https.php……………</ p> 

<?php

$sessionID = $_GET['session'];

session_id($sessionID);

session_start();

if (!empty($_SESSION['demo'])) {
echo $_SESSION['svnlabs'];
} else {
echo ‘Demo session failed’;
}

?>

IE7：このページには安全なアイテムと安全でないアイテムの両方が含まれています

IEメッセージの安全なアイテムと安全でないアイテムを回避するには、css、js、画像、フラッシュなど、ページ上のすべての静的リソースに相対パスを使用する必要があります…</ p>

IEメッセージ IEメッセージ

于 2011-11-17T09:48:23.573 に答える
1

暗号化された情報の転送についてここでほとんど述べられていることに加えて、サードパーティのAPIを介して機密情報を転送する場合と同じように見ることをお勧めします。誰かがリクエストをスプーフィングしていないことをどうやって知ることができますか？セットアップの機密性に応じて、リクエストの信頼性を真に確認するためのプロトコルは多数あります。注意しないと、アカウントが侵害される可能性があります。

同じサーバー上にある場合でも、次のことを考慮してください。

誰かが暗号化されたキーを通過するリンクやフォームアクションなどをたどっている場合、セキュリティで保護されたバージョンのサイトにアクセスする前に、誰かがそれを盗聴するのを防ぐにはどうすればよいでしょうか。私が公共のWIFIスポットにいたとしても、それはそれほど大げさなことではありません。私はあなたのサイトのふりをして、リクエストを自分のラップトップに再ルーティングし、トークンを取得して、訪問者を元の場所にリダイレクトすることができます。彼らはそれがグリッチであると思い込み、そして何も知らないでしょう。今、私は彼らとしてログインすることができ、おそらく彼らのクレジットカードを登録して$ 10,000相当のものを購入し、それを別の場所に発送することができます。ここで注意する程度は、感度の程度と一致する必要があります。

また、トークンの有効期限が切れていることを確認してください（1回の使用のみ、X秒後など）が、両端でPost-Redirect-Getパターンを使用することも検討します。

ページ上またはセキュリティで保護されていないサイトの形式で直接リンクを表示しないでください。ただし、バックエンドでリダイレクトする（そしてすべてのトークン/暗号化を処理する）リンクを表示してください。保護されたバージョンに到達したら、同じことを行います（URLに「？token = asdfjalksfjla」パラメーターをそのまま残さないでください。リダイレクトしてください）。

したがって、正式なトークンベースのシステムはこの問題を解決するように設計されていますが、これだけのためにOAuthを実装するのはやり過ぎかもしれません。実行する前に、潜在的な脆弱性の計画に時間をかけてください。トークンを推測するのが本当に難しいからといって、それが不可能である（または衝突が発生しなかったなど）という意味ではないので、それに応じて計画してください。

また、PHPの組み込みハンドラーよりも高度なセッション管理システムが必要になる場合があります。PHPに複数の訪問にわたってセッションを継続させることができるかどうかはわかりません（プロトコルの切り替えはそのように扱われます）。

于 2011-11-16T12:14:09.217 に答える
1

セッション Cookie はセキュア フラグで作成されているようですが、セッション Cookie が渡されないため、チェックアウト ページの URL に問題があります。

または、おそらく、セッション Cookie が安全ではありません。単に、チェックアウト ページの URL が十分に異なっており ( http://mysite.comとhttp://www.mysite.com )、ブラウザーが Cookie を送信していないことが原因です。

http から https への切り替え、およびその逆の切り替えについて詳しく知りたい場合は、選択的 ssl に関する私の記事をご覧ください:-)

于 2009-02-26T21:42:39.190 に答える
1

すべてのページで HTTPS を使用することを検討してください。これは、この問題を回避する最も簡単な方法であり、サイトのセキュリティを向上させます。

すべてのページに SSL を使用できない場合は、次のアプローチを使用できます: 安全なセッション Cookie を使用して HTTP ページと HTTPS ページを切り替えます。背後にある考え方は、セッション Cookie を安全でない (したがって、HTTP および HTTPS ページで使用できる) ままにし、認証を処理するための 2 つ目の安全な Cookie を用意するというものです。これは、「セッションの維持」と「認証」という 2 つの問題を分離する良い方法です。

于 2011-11-16T12:48:43.347 に答える
0

Cookie が失われているように見えるため、これは不可能な場合があります。使用しているブラウザは、完全に別のドメイン用であると考えている必要があります。

具体的にどのブラウザを使用していますか？

于 2009-01-14T01:00:28.857 に答える
0

私は同様の問題を抱えていましたが、この解決策は私にとっては良かったです。おそらく将来的に他の人を助けるでしょう

これをphp.iniに追加します

suhosin.session.cryptdocroot = オフ

suhosin.cookie.cryptdocroot = オフ

于 2016-07-26T19:21:07.227 に答える
0

専用IPはありますか？一部の共有環境では、https と http は異なるサーバーを介してルーティングされるため、Cookie を切り替えると実際には Cookie へのアクセスが失われます。これは、Cookie が異なるドメインにあるためです。

解決策は次のとおりです。専用IP

常にすべてのページで https を強制する

于 2015-07-13T16:40:22.390 に答える
0

デフォルトでは、ブラウザは http と https への接続を完全に異なるセッションとして扱うことを期待しています。http://someUrl/とhttps://someUrl/が同じページを指すという慣習がありますが、それは保証されていません。ポート 80 (http) とポート 443 (https) でまったく異なるサイトを実行することができます。

私は PHP を知りませんが、通常、安全なセッションと安全でないセッションの間でセッション変数が自由に利用できるとは思っていません。たとえば、最後のチェックアウトのクレジット カード番号が、その後のすべての安全でないページで利用できるとは思っていません。訪問。

権威のない答えを許してください。しかし、答えがあまりないので、2cを捨てると思いました。

于 2009-01-14T02:29:10.907 に答える
-1

HTTPS は安全であることを意図しており、HTTPS が役割を果たしているため、これは正常な動作です。

以下は、HTTP から HTTPS への切り替え中にセッションを維持できるいくつかのトリックです。

  1. GET を使用してページ間でセッション ID を送信する

  2. POST による POST セッション ID

  3. ファイルを使用してセッションを保存する

  4. セッションに Cookie を使用する

  5. データベースを使用してセッションを保存する

私の返信を通して、あなたが何かを得られることを願っています。

于 2011-11-16T11:36:05.443 に答える