php - seguro - pasar moodle de http a https

Sesión perdida al cambiar de HTTP a HTTPS en PHP

Question

Al enviar al usuario a una página de pago, se cambian de http://sitename.com a https://sitename.com .

Como resultado, las variables $_SESSION se pierden.

El sitio tiene un certificado SSL válido que puede o no ser de alguna utilidad.

Answer 1

¿Tienes una IP dedicada? en algunos entornos compartidos, el https y el http se enrutan a través de diferentes servidores, por lo que el cambio en realidad pierde el acceso a las cookies ya que están en dominios diferentes.

las soluciones serían: IP dedicada

forzando https en todas las páginas en todo momento

Answer 2

Considere usar HTTPS para todas las páginas, esa es la manera más fácil de evitar este problema y mejorará la seguridad de su sitio.

Si SSL para todas las páginas no es una opción para usted, entonces podría utilizar este enfoque: Cambiar entre las páginas HTTP y HTTPS con la cookie de sesión segura . La idea detrás es que deje la cookie de sesión insegura (y, por lo tanto, esté disponible para las páginas HTTP y HTTPS), pero tenga una segunda cookie segura para manejar la autenticación. Es una buena manera de separar las dos preocupaciones "mantener la sesión" y "autenticación".

Answer 3

Cuando cambia entre los servicios HTTP y HTTPS en el mismo servidor, su ID de sesión HTTP no se pasa a la sesión HTTPS. Puede configurarlo pasando la ID de la sesión de la página HTTP a la página HTTPS de una de tres maneras posibles:

Desde PHP: session_start :

session_start() crea una sesión o reanuda la actual en función de la ID de sesión actual que se pasa a través de una solicitud, como GET, POST o una cookie

Cuando está utilizando sesiones, normalmente comenzará su script con session_start() . Si el navegador tiene una cookie de ID de sesión establecida, session_start() usará esa ID de sesión. Si el navegador no tiene una cookie de ID de sesión establecida, session_start() creará una nueva.

Si la ID de la sesión no está configurada (en su ejemplo, el navegador está creando una nueva cookie de ID de sesión para la sesión HTTPS), puede configurarla usando la función session_id() . session_id() también devuelve convenientemente el ID de sesión como una cadena. Asi que

...

$currentSessionID = session_id();

...

establece la variable $currentSessionID igual a la ID de sesión actual, y

...

session_id($aSessionID);

...

establece la cookie sessionID en el navegador en $aSessionID . de PHP: session_id

Aquí hay un ejemplo con dos scripts. Uno se accede a través de HTTP y el otro se accede a través de HTTPS. Deben estar en el mismo servidor para mantener los datos de la sesión.

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

?>

Para que esto funcione, los servidores HTTP y HTTPS deben usar el mismo sustrato de almacenamiento de datos de sesión (es decir, para el controlador de archivos predeterminado, ejecutar en la misma máquina física con el mismo php.ini). Aquí hay algunos fallos de seguridad, por lo que no usaría este código para transferir información confidencial. Simplemente se entiende como un ejemplo viable.

Cuando me encontré con este problema antes, se me ocurrió lo anterior como una solución rápida, pero acabo de recordar la causa original del problema. Iba de http://www.example.com/page.php a https://example.com/page.php (observe la ausencia de "www"). Asegúrese de que http://www.example.com/page.php se vincule con https://www.example.com/page.php y http://example.com con un enlace a https://example.com/page.php .

PD, en realidad no ejecuté estas secuencias de comandos por lo que puede haber un error tipográfico o dos que impida que se ejecuten correctamente como están.

Answer 4

De manera predeterminada, esperaría que un navegador trate las conexiones a http y https como sesiones completamente diferentes. Aunque la convención es que http: // someUrl / y https: // someUrl / apuntará a la misma página, no está garantizado. Puede tener sitios completamente diferentes que se ejecutan en el puerto 80 (http) y el puerto 443 (https).

No sé PHP, pero en general no esperaría que las variables de sesión estuvieran disponibles libremente entre sesiones seguras y no seguras, por ejemplo, no esperaría que el número de tarjeta de crédito de mi último pago estuviera disponible para todas las páginas inseguras subsiguientes. visitar.

Perdone la respuesta no autorizada, pero pensé que podría arrojarla en mi 2c ya que no hay muchas respuestas.

Answer 5

Esto puede no ser posible ya que la cookie parece perderse. El navegador que estás utilizando debe pensar que es para un dominio completamente diferente.

¿Qué navegador estás usando específicamente?

Answer 6

La siguiente solución asume que los servidores seguros y no seguros tienen acceso a los mismos servicios de back-end (caché, almacén de bases de datos, etc.).

Tuvimos que lidiar con este mismo problema al enviar a un usuario a nuestro flujo de pago cuando terminaron de comprar. Para resolver esto, implementamos una capa de almacenamiento en caché y almacenamos en caché todos los datos pertinentes. Por ejemplo, obtendríamos los id. De productos y el ID de usuario de los valores de la sesión, los serializaríamos, crearíamos un hash y finalmente almacenaríamos los datos de la sesión dentro del caché usando el hash como la clave. Luego redirigiríamos al usuario al sitio seguro con el hash en la url.

Cuando el usuario termina en el sitio seguro, intentamos extraer los datos del caché en función del hash. Luego, con la identificación del usuario y los identificadores de productos, podríamos cargar todos los datos de precios y descripciones de la base de datos y presentarlos al usuario para su revisión final.

Existe un riesgo heredado porque los datos de la memoria caché son volátiles, pero nunca hemos tenido problemas ya que la redirección ocurre rápidamente.

Answer 7

No puede pasar valores de sesión entre diferentes dominios. Debe usar http post-get o una base de datos para pasar sus valores. Por seguridad, puede concaturar todos sus valores en una cadena y usar

sha1($string)

y publícalo al lado de tus valores y calcula el sha1 para los valores que obtiene la otra página, luego compara los valores hash.

El método de publicación en diferentes dominios hace que los navegadores muestren un mensaje de seguridad, así que no lo use.

El uso de la URL para obtener el método no es seguro, deberá solicitar una contraseña en la página redirigida para permitir los parámetros de obtención en su sistema.

No use cookies si necesita seguridad.

Lo que sugiero es guardar los valores en una base de datos y generar una clave, luego hacer su enlace de redirección usando su clave, reenviar la página de los usuarios con un parámetro get que tiene la clave, luego el usuario de la página se redirige para obtener esa clave , busca los datos y elimina la clave. puedes generar una clave con 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

esto es bastante seguro

las cosas que pueden suceder: una secuencia de comandos que ingresa valores aleatorios para el parámetro "clave" para hacer que su sitio web cargue los datos en su memoria?

Esto no sucederá porque eliminas la entrada después de usarla. Algunos conceptos erróneos comunes son que los valores de obtención son inseguros y siempre deben evitarse.

puede establecer el tipo de motor de tabla en "memoria" en mysql si desea la perfección de rendimiento.

Answer 8

No se preocupe, este es un comportamiento normal porque HTTPS está destinado a ser seguro y está haciendo su parte.

A continuación hay algunos trucos a través de los cuales puede mantener la sesión mientras cambia de HTTP a HTTPS.

1. Transmitir ID de sesión entre páginas usando GET

2. POST ID de la sesión por POST

3. Usa archivos para guardar sesiones

4. Use cookies para las sesiones

5. Usa la base de datos para guardar la sesión

Espero que obtengas algo a través de mi respuesta.

Answer 9

Parece que la cookie de sesión está configurada para ser segura. Las cookies tienen un indicador "secure" que, si se establece en verdadero, significa que la cookie no se enviará a sitios que no sean https. PHP probablemente esté usando eso para sus cookies de sesión. Puede cambiar esto con la función session_set_cookie_params , o con la configuración session.cookie_secure en php.ini.

Answer 10

Parece que la cookie de sesión se creó con el indicador de seguridad, pero hay algo en la url de la página de pago debido a que la cookie de sesión no se pasa.

O, probablemente, su cookie de sesión no es segura, solo que la URL de la página de pago es lo suficientemente diferente ( http://mysite.com vs http://www.misitio.com ) que el navegador no está enviando la cookie.

Si desea leer más sobre cómo pasar de http a https y viceversa, eche un vistazo a mi descripción en select ssl :-)

Answer 11

Puede administrar la sesión entre HTTP a HTTPS o HTTPS a HTTP:

1. Transmitir ID de sesión entre páginas usando GET

2. POST ID de la sesión por POST

3. Usa archivos para guardar sesiones

4. Use cookies para las sesiones

5. Usa la base de datos para guardar la sesión

Debajo del ejemplo se puede usar para transmitir usando GET ...

Archivo: 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>’;

?>

Archivo: https.php ...............

<?php

$sessionID = $_GET[''session''];

session_id($sessionID);

session_start();

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

?>

IE7: esta página contiene elementos seguros y no seguros

Debe usar la ruta relativa para todos los recursos estáticos en la página como css, js, imágenes, flash, etc. para evitar los mensajes IE de elementos seguros y no seguros ...

Mensaje de IE

Answer 12

Recomiendo, además de lo que la mayoría ha dicho aquí, transferir información cifrada, mirándola igual que si transfiriera información confidencial a través de una API de un tercero. ¿Cómo sabes que alguien no está falsificando la solicitud? Existen muchos protocolos para confirmar realmente la autenticidad de la solicitud, dependiendo de qué tan sensible sea su configuración. Te estás abriendo a cuentas comprometidas si no tienes cuidado.

Aunque está en el mismo servidor, considere esto:

Cuando alguien está siguiendo el enlace, forma acción, etc. que pasa sobre la clave encriptada, ¿qué evitaría que alguien lo olfatee ANTES de llegar a la versión segura de su sitio? Si estuviera en un punto WIFI público, eso no sería demasiado descabellado. Podría fingir que soy su sitio, redirigir las solicitudes a mi computadora portátil, tomar el token y redirigir al visitante de regreso a donde vinieron. Asumirían que era un problema y no tendrían idea. Ahora puedo iniciar sesión como ellos, y posiblemente ir a comprar cosas por valor de $ 10.000 con su tarjeta de crédito registrada y enviarla a otro lugar. El grado de precaución que tome aquí debe coincidir con el grado de sensibilidad.

Además, asegúrese de caducar sus tokens (un solo uso, después de X cantidad de segundos, etc.), pero también consideraría usar el patrón Post-Redirect-Get en ambos extremos, es decir:

No muestre el enlace directo en una página o en forma de sitio no seguro, pero muestre un enlace que luego redireccionará en el back-end (y manejará todo el token / encriptación). Cuando llegue a la versión segura, haga lo mismo (no deje un parámetro "? Token = asdfjalksfjla" simplemente sentado allí en la URL; redirigirlo).

Entonces, los sistemas formales basados ​​en tokens fueron diseñados para resolver este mismo problema, pero implementar OAuth solo por esto podría ser excesivo. Dedique un tiempo a planificar las posibles vulnerabilidades antes de ejecutar. El hecho de que sería muy difícil adivinar el token no significa que sea imposible (o que no haya colisiones, etc.), así que planifíquelo en consecuencia.

También es posible que necesite un sistema de administración de sesión más sofisticado que los manejadores integrados de PHP. No sé si puede obligar a PHP a continuar una sesión en múltiples visitas (los protocolos de conmutación se tratan de esa manera).

Answer 13

Tenía un problema similar, sin embargo, esta solución fue buena para mí, tal vez ayudará a otros en el futuro

agregue esto en su php.ini

suhosin.session.cryptdocroot = Off

suhosin.cookie.cryptdocroot = Off

Answer 14

Tengo una solución con esto ... Pruébalo.

$_SESSION[''test''] = ''test'';
session_regenerate_id(true);

header("Location: /");// the header must be sent before session close
session_write_close(); // here you could also use exit();

Answer 15

Tuvimos este problema también. Resultó ser porque estábamos usando el parche suhosin en nuestra instalación de PHP. Lo solucionamos configurando suhosin.session.cryptdocroot = Off en /etc/php.d/suhosin.ini .

Para el manual de suhosin.session.cryptdocroot sobre suhosin.session.cryptdocroot consulte http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptdocroot .

Originalmente encontramos la solución de esta publicación de blog: http://www.yireo.com/blog/general-news/315-switch-between-http-and-https-looses-php-session .