Perte de session lors du passage de HTTP à HTTPS en PHP

Question

En envoyant l'utilisateur vers une page de paiement, il passe de http://sitename.com a https://sitename.com .

En conséquence, $_SESSION les variables sont perdues.

Le site dispose d'un certificat SSL valide qui peut ou non être utile.

Answer 1

Lorsque vous passez du service HTTP au service HTTPS sur le même serveur, votre ID de session HTTP n'est pas transmis à la session HTTPS. Vous pouvez le définir en transmettant l'ID de session de la page HTTP à la page HTTPS de l'une des trois manières possibles :

De PHP : session_start :

session_start() crée une session ou reprend la session actuelle en se basant sur en fonction de l'identifiant de session actuel transmis par une requête, telle que GET, POST, ou un cookie

Lorsque vous utilisez des sessions, vous démarrez normalement votre script avec session_start() . Si le navigateur dispose d'un cookie d'identification de session, session_start() utilisera cet identifiant de session. Si le navigateur ne dispose pas d'un cookie d'identification de session, session_start() en créera un nouveau.

Si l'ID de session n'est pas défini (dans votre exemple, le navigateur crée un nouveau cookie d'ID de session pour la session HTTPS), vous pouvez le définir à l'aide de la commande session_id() fonction. session_id() renvoie également l'ID de la session sous forme de chaîne. Ainsi,

...

$currentSessionID = session_id();

...

définit le $currentSessionID égale à l'ID de la session en cours, et

...

session_id($aSessionID);

...

fixe le cookie sessionID dans le navigateur à $aSessionID . de PHP : session_id

Voici un exemple avec deux scripts. L'un est accessible via HTTP et l'autre via HTTPS. Ils doivent être sur le même serveur pour maintenir les données de session.

script 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>';

?>

script 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.';
}

?>

Pour que cela fonctionne, les serveurs HTTP et HTTPS doivent utiliser le même substrat de stockage des données de session (c'est-à-dire, pour le gestionnaire de fichiers par défaut, fonctionner sur la même machine physique avec le même php.ini). Il y a quelques failles de sécurité ici, donc je n'utiliserais pas ce code pour transférer des informations sensibles. Il s'agit simplement d'un exemple pratique.

Lorsque j'ai rencontré ce problème auparavant, j'ai proposé la solution ci-dessus comme solution rapide, mais je me suis souvenu de la cause initiale du problème. Je passais de http://www.example.com/page.php a https://example.com/page.php (remarquez l'absence de "www"). Assurez-vous que http://www.example.com/page.php sera lié à https://www.example.com/page.php y http://example.com sera lié à https://example.com/page.php .

PS, je n'ai pas réellement exécuté ces scripts, il peut donc y avoir une ou deux fautes de frappe qui les empêchent de fonctionner correctement tels quels.

Answer 2

On dirait que le cookie de session est configuré pour être sécurisé. Les cookies ont un "sécurisé" qui, s'il est défini à true, signifie que le cookie ne sera pas envoyé aux sites non-https. PHP l'utilise probablement pour ses cookies de session. Vous pouvez changer cela avec l'option session_set_cookie_params ou avec la fonction session.cookie_secure dans le php.ini.

Answer 3

Nous avons également eu ce problème. Il s'est avéré que c'était dû au fait que nous utilisions l'option suhosin sur notre installation de PHP. Nous le corrigeons en mettant suhosin.session.cryptdocroot = Off en /etc/php.d/suhosin.ini .

Pour le manuel suhosin sur suhosin.session.cryptdocroot voir http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptdocroot .

Nous avons trouvé le correctif dans cet article de blog : http://www.yireo.com/blog/general-news/315-switch-between-http-and-https-looses-php-session .

Answer 4

La solution suivante suppose que les serveurs sécurisés et non sécurisés ont accès aux mêmes services dorsaux (cache, magasin de base de données, etc.).

Nous avons dû faire face à ce même problème lorsque nous avons envoyé un utilisateur vers notre flux de paiement lorsqu'il avait terminé ses achats. Pour résoudre ce problème, nous avons mis en place une couche de mise en cache et mis en cache toutes les données pertinentes. Par exemple, nous glanons les identifiants du produit et de l'utilisateur à partir des valeurs de session, nous les sérialisons, nous créons un hachage et nous stockons enfin les données de session dans le cache en utilisant le hachage comme clé. Nous redirigerions ensuite l'utilisateur vers le site sécurisé avec le hash dans l'url.

Lorsque l'utilisateur arrive sur le site sécurisé, nous essayons d'extraire les données du cache en fonction du hachage. Ensuite, avec l'identifiant de l'utilisateur et les identifiants des produits, nous pouvons charger toutes les données de prix et de description de la base de données et les présenter à l'utilisateur pour la vérification finale.

Il y a un risque inhérent au fait que les données du cache sont volatiles, mais nous n'avons jamais eu de problèmes avec cela car la redirection se fait rapidement.

Answer 5

Il semble que votre cookie de session soit créé avec le drapeau sécurisé, mais il y a quelque chose avec l'url de votre page de paiement à cause duquel le cookie de session n'est pas transmis.

Ou probablement, votre cookie de session n'est pas sécurisé - juste que l'url de la page de paiement est suffisamment différente ( http://mysite.com vs http://www.mysite.com ) que le navigateur n'envoie pas le cookie.

Si vous souhaitez en savoir plus sur le passage de http à https et vice versa, jetez un coup d'oeil à à mon article sur le ssl sélectif :-)