security ssl https

security - http to https wordpress



¿Es una mala idea redirigir http a https? (6)

Estoy leyendo esta página y dice que si un sitio es SSL y el usuario intenta acceder a él a través de http habitual, la aplicación no debe redireccionar al usuario a https. Debería simplemente bloquearlo. ¿Alguien puede verificar la validez de esto? No parece una buena idea, y me pregunto cuál es el riesgo real de solo reenviar al usuario a https. Parece que no hay razones técnicas detrás de esto, solo que es una buena forma de educar al usuario.

Deshabilite el acceso HTTP al dominio, ni siquiera lo redireccione o vincule a SSL. Simplemente informe a los usuarios que este sitio web no es accesible a través de HTTP y que deben acceder a él a través de SSL.

Esta es la mejor práctica contra los ataques MITM y phising. De esta forma, sus usuarios recibirán información sobre esa aplicación que nunca se puede acceder a través de HTTP, y cuando se encuentren con un ataque phishing o MITM sabrán que algo está mal.

Una de las mejores formas de proteger su aplicación contra los ataques MITM y los ataques phising es educar a sus usuarios.

Acabo de notar esta pregunta, pero he escrito un par de respuestas a preguntas similares:

No creo que el redireccionamiento de HTTP a HTTPS sea necesariamente dañino, pero esto debe hacerse cuidadosamente. Lo importante es que no debe confiar en que estas redirecciones automáticas estén presentes durante la fase de desarrollo. Deben, como mucho, usarse para usuarios que escriben la dirección en el navegador por sí mismos.

También es responsabilidad exclusiva del usuario verificar que estén utilizando HTTPS (y que el certificado se verifique sin aviso) cuando lo esperan.

Los riesgos reales de cambiar de HTTP a HTTPS es que puede confiar de manera confiable en lo que se hizo antes del cambio, si elige mantener la sesión. El flujo y el proceso de su sitio web deben tener esto en cuenta.

Por ejemplo, si sus usuarios navegan por su sitio de compras y agregan varios artículos al carro usando HTTP y planifica usar HTTPS para obtener los detalles del pago, también debe hacer que el usuario confirme el contenido de su cesta mediante HTTPS.

Además, al cambiar de HTTP a HTTPS, es posible que tenga que volver a autenticar al usuario y descartar el identificador de sesión HTTP simple, si lo hay. De lo contrario, un atacante podría usar esa cookie para moverse a esa sección HTTPS del sitio y potencialmente suplantar al usuario legítimo.

Desde la perspectiva técnica, IMO no hay ningún efecto secundario además de lo que HTTPS lleva.

Desde la perspectiva de UX / UI, se recomienda usar la redirección de clics o retraso, proporcionando una indicación visual para preguntar a las personas que escriben la URL de HTTPS en primer lugar, ya que la redirección está sujeta al ataque de MITM. Sin embargo, no muchos sitios web de HTTPS hacen esto, ya que proporcionan imágenes que piden a las personas que busquen el ícono de bloqueo en el navegador en sus páginas HTTPS.

Es un método "bootstrap" perfectamente aceptable: 301 redirecciona de HTTP a HTTPS y luego, en el lado de HTTPS, devuelve un encabezado de Strict-Transport-Security para bloquear el navegador en HTTPS.

Sería un gran problema de usabilidad bloquear completamente HTTP, ya que los navegadores web intentarán el protocolo HTTP cuando se ingrese una URL sin designador de protocolo, a menos que el navegador admita HSTS y se encuentre un token HSTS en la caché del navegador o en la lista de precarga. .

No veo ningún riesgo técnico (excepto el de la actualización al final de mi respuesta) al redirigir de HTTP a HTTPS. Por ejemplo, gmail y yahoo mail lo están haciendo. Puede verificarlo utilizando una herramienta de depuración HTTP (como Fiddler), donde puede claramente la respuesta de redireccionamiento 302 devuelta por el servidor.

Creo que el bloqueo es una mala idea desde una perspectiva de usabilidad. Muchas veces los usuarios ingresan una dirección en el navegador sin especificar HTTP o HTTPS. Por ejemplo, accedo a gmail escribiendo "mail.google.com", que de manera predeterminada es "http://mail.google.com" y que se redirige automáticamente a "https://mail.google.com". Sin la redirección automática siempre tendré que escribir la dirección completa.

Estoy de acuerdo con el artículo citado de que HTTPS es el mejor método contra los ataques de MITM, pero no estoy de acuerdo con que sea la mejor práctica contra phising. La educación del usuario es de hecho un factor clave en contra de los ataques de phishing (los usuarios tienen que verificar que estén accediendo al sitio desde el dominio correcto), pero de ninguna manera puede hacer esa educación al bloquear la redirección HTTP a HTTPS.

Actualiza @Pedro y @Spolto tienen razón. Se debe tener especial cuidado con las cookies sensibles (como las cookies de sesión o de autenticación), que de hecho deben marcarse como seguras, de modo que solo se transmitan a través de HTTPS. Me he perdido ese. +1 ustedes dos.

Pasar de HTTP a HTTPS es en realidad una idea no tan buena. Por ejemplo, un atacante podría hacer un ataque man-in-the-middle usando una herramienta como thoughtcrime.org/software/sslstrip . Para resolver este problema, debe usar el protocolo HSTS . Es compatible con todos los principales navegadores (Internet Explorer, que es el último en adoptar, lo está apoyando a partir de IE12), y en uso en muchos de los principales sitios (por ejemplo, Paypal, Google).

Una solicitud HTTP que incluye una cookie de identificación de sesión está sujeta a ataques de secuestro de sesión. Es importante que si permite HTTP y redirige a HTTPS, esas cookies se marcan como seguras.

No veo ningún motivo técnico por el que HTTP deba bloquearse por completo tampoco, y muchos sitios reenvían HTTP a HTTPS. Al hacer esto, es muy recomendable implementar HTTP Strict Transport Security (HSTS), que es un mecanismo de seguridad web que declara que los navegadores solo deben usar conexiones HTTPS.

HSTS se implementa especificando un encabezado de respuesta como Strict-Transport-Security: max-age=31536000 . El cumplimiento de los agentes de usuario convertirá automáticamente los enlaces inseguros en enlaces seguros, lo que reducirá el riesgo de ataques de intermediarios. Además, si existe el riesgo de que el certificado no sea seguro, p. Ej., No se reconoce la autoridad raíz, se muestra un mensaje de error y no se muestra la respuesta.