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

Vous ne pouvez pas transmettre les valeurs de session entre différents domaines. Vous devez utiliser http post-get ou une base de données pour transmettre vos valeurs. Pour des raisons de sécurité, vous pouvez concaténer toutes vos valeurs dans une chaîne de caractères et utiliser la commande

sha1($string)

et le poster à côté de vos valeurs et calculer le sha1 pour les valeurs que l'autre page obtient, puis comparer les hashs.

La méthode d'affichage sur des domaines différents entraîne l'affichage d'un message de sécurité par les navigateurs, alors n'utilisez pas cette méthode.

Utiliser l'url pour la méthode get n'est pas sûr, vous devrez demander un mot de passe sur la page redirigée pour autoriser les paramètres get dans votre système.

N'utilisez pas de cookies si vous avez besoin de sécurité.

La méthode que je suggère est la suivante : enregistrez les valeurs dans une base de données et générez une clé, puis créez votre lien de redirection en utilisant votre clé, faites suivre la page de l'utilisateur avec un paramètre get qui contient la clé, puis la page vers laquelle l'utilisateur est redirigé obtient cette clé, récupère les données et supprime la clé. vous pouvez générer une clé avec sha1

PAGE 1---
$key=sha1($allvalsconcat);
//insert your session values to a database also the key in a column
header("Location: page2.php?key=".$key);

PAGE 2---
// select from database where key=$_GET["key"];
// delete from table where key=$key

c'est assez sûr.

les choses qui peuvent arriver : un script entrant des valeurs aléatoires pour le paramètre "clé" pour que votre site web charge les données dans votre mémoire ?

Cela ne se produira pas parce que vous supprimez l'entrée après l'avoir utilisée. Une idée fausse courante est que les valeurs get ne sont pas sûres et doivent toujours être évitées.

vous pouvez définir le type de moteur de table sur "mémoire" dans mysql si vous souhaitez améliorer les performances.

Answer 2

Je recommande, en plus de ce qui a été dit ici sur le transfert d'informations cryptées, de considérer la situation de la même manière que si vous transfériez des informations sensibles via une API tierce. Comment savez-vous que quelqu'un n'usurpe pas la demande ? Il existe de nombreux protocoles pour confirmer l'authenticité de la demande, en fonction de la sensibilité de votre installation. Si vous ne faites pas attention, vous vous exposez à ce que des comptes soient compromis.

Même si c'est sur le même serveur, considérez ceci :

Lorsque quelqu'un suit le lien, l'action du formulaire, etc. qui transmet la clé cryptée, qu'est-ce qui empêcherait quelqu'un de la renifler AVANT d'arriver à la version sécurisée de votre site ? Si je me trouvais dans un endroit public WIFI, ce ne serait pas trop compliqué. Je pourrais me faire passer pour votre site, rediriger les requêtes vers mon propre ordinateur portable, récupérer le jeton et rediriger le visiteur vers son point d'origine. Ils supposeraient que c'était un pépin, et n'en auraient aucune idée. Maintenant, je peux me connecter en tant qu'eux, et peut-être aller acheter pour 10 000 $ de marchandises avec leur carte de crédit dans le dossier et les expédier ailleurs. Le degré de prudence que vous prenez ici doit correspondre au degré de sensibilité.

Veillez également à faire expirer vos jetons (à usage unique, après un nombre X de secondes, etc.), mais j'envisagerais également d'utiliser le modèle Post-Redirect-Get aux deux extrémités, c'est-à-dire :

Ne montrez pas le lien direct sur une page ou sous la forme du site non sécurisé, mais montrez un lien qui redirigera ensuite sur le backend (et gérera tous les trucs de jeton/chiffrement). Lorsque vous arrivez sur la version sécurisée, faites de même (ne laissez pas un paramètre "?token=asdfjalksfjla" dans l'URL, redirigez-le).

Ainsi, les systèmes formels basés sur des jetons ont été conçus pour résoudre ce problème précis, mais la mise en œuvre d'OAuth juste pour cela pourrait être exagérée. Passez un peu de temps à planifier les vulnérabilités potentielles avant d'exécuter. Ce n'est pas parce que ce serait vraiment difficile pour deviner le jeton ne signifie pas que c'est impossible (ou qu'il ne peut pas y avoir de collisions, etc.), alors planifiez en conséquence.

Vous pouvez également avoir besoin d'un système de gestion de session plus sophistiqué que les gestionnaires intégrés de PHP. Je ne sais pas si vous pouvez forcer PHP à poursuivre une session sur plusieurs visites (le changement de protocole est traité de cette façon).

Answer 3

Pensez à utiliser HTTPS pour toutes les pages, c'est le moyen le plus simple d'éviter ce problème et cela améliorera la sécurité de votre site.

Si le SSL pour toutes les pages n'est pas une option pour vous, vous pouvez utiliser cette approche : Basculer entre les pages HTTP et HTTPS avec un cookie de session sécurisé . L'idée est de laisser le cookie de session non sécurisé (et donc accessible aux pages HTTP et HTTPS), mais d'avoir un second cookie sécurisé pour gérer l'authentification. C'est un bon moyen de séparer les deux préoccupations "maintien de la session" et "authentification".

Answer 4

Vous pouvez gérer la session entre HTTP et HTTPS ou HTTPS et HTTP :

1. Transmettre l'ID de session entre les pages en utilisant GET

2. ID de session par POST

3. Utiliser des fichiers pour sauvegarder les sessions

4. Utiliser des cookies pour les sessions

5. Utiliser la base de données pour sauvegarder la session

L'exemple ci-dessous peut être utilisé pour transmettre en utilisant GET ..

Fichier : http.php

<?php

session_start();

$sessionID = session_id();

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

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

?>

Fichier : https.php

<?php

$sessionID = $_GET['session'];

session_id($sessionID);

session_start();

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

?>

IE7 : Cette page contient des éléments sécurisés et non sécurisés.

Vous devez utiliser un chemin relatif pour toutes les ressources statiques de la page, comme les css, les js, les images, les flashs, etc. pour éviter qu'IE ne signale les éléments sécurisés et non sécurisés

IE Message

Answer 5

Cela peut ne pas être possible car le cookie semble se perdre. Le navigateur que vous utilisez doit penser qu'il s'agit d'un domaine complètement différent.

Quel navigateur utilisez-vous spécifiquement ?