Javascript http a https redirect - ¿qué tan vulnerable / seguro está? [duplicar]

2

Si tuviera un sitio web enlace que redireccionara a enlace a través de javascript (con un HTTP/1.1 403 Forbidden ), ¿cuáles son los vectores de ataque que podrían ser vulnerables también?

¿Por qué esto no es una buena práctica? (y la forma preferida es hacer un 301 desde el lado del servidor)

  1. ok SEO, mientras que se prefiere un 301 para los robots de búsqueda.
  2. inhabilita la secuencia de comandos en el navegador, estás bloqueado

¿Algo más?

Para una sola cosa, según mi opinión, una fijación de sesión a través de MITM no es posible, al menos porque toda la respuesta bruta que me da es la siguiente. No hay ninguna cookie, en absoluto.

<html>
<head><title>hussh...</title></head>
<script language="JavaScript">
function redrToHttps()
{
 var httpURL= window.location.hostname + window.location.pathname + window.location.search;
 var httpsURL= "https://" + httpURL;
 window.location = httpsURL;
}
 redrToHttps();
</script>
<body>

No sé por qué muchos tutoriales en Internet recomiendan que lo hagas a través de javascript, mientras que un 301 permanente es una opción perfecta. AFAIK, no pude encontrar un vector de ataque en esta forma de redireccionamiento a través de javascript con 403 encabezado.

¿Me estoy perdiendo algo? ¿Hay algún vector de ataque que pueda enfrentar en el futuro? ¿Por qué no es esta la forma recomendada?

Editar:

Se me olvidó mencionar por qué publiqué esta pregunta. Ya he levantado una bandera para usar HSTS, faltaba en el sitio web en cuestión. Mi preocupación es que las personas que desarrollaron esta aplicación siguieron el primer enlace en google (en ese entonces, cuando se desarrollaron) para hacer esta redirección de http a https a través de javascript. Honestamente, esta es la primera vez que veo un http a https redirect para todas las páginas de la aplicación a través de javascript. No tengo que decirle lo malo que es, y estúpido el javascript https redirecciona los sonidos, incluso desde el principio. Pero miré la respuesta bruta, había un 403 que está bien (hey, estás prohibido), aunque no es la mejor manera de hacerlo.

El sitio nunca sirve ninguna información a través de http. Siempre utiliza el javascript para hacer la redirección hacer una nueva solicitud. Demasiado. Lo entiendo. Pueden ser sus respuestas / pensamientos acerca de cuán susceptible podría ser esto, ayudaría a vender por qué es una idea tan mala en términos de seguridad.

Me temo que este no es un posible duplicado, ya que ninguna pregunta en la red de stackexchange analiza las implicaciones de seguridad de una redirección de http a https a través de javascript en particular. Manteniendo las mejores prácticas aparte, agradecería sus ideas sobre cuán inseguro (y por qué) es este enfoque .

El script del lado del cliente personalizado que indica al navegador que navegue a una página diferente, y el navegador que responde a un 301 como en enlace tiene diferencias fundamentales, creo . ¿Hay alguna hazaña conocida demostrada en este caso?

Gracias.

Edición 2: ¿Alguien notó un 403? En IIS 6, si tenía habilitado, requiere HTTPS y si intentó acceder al sitio a través de HTTP y si no había configurado SSL correctamente, entonces eso es lo que obtendría una página de error 403 aburrida. La solución de solución rápida de antaño es atrapar un 403 en el servidor y devolver una página de error personalizada que contendría un código javascript como mencioné en la pregunta. Ese javascript solicitaría entonces la versión HTTPS de la página, que es una nueva solicitud del navegador y no una redirección de ningún tipo. Lo que en realidad es equivalente a una nueva solicitud https. Esto es mala, muy mala, mala implementación. Pero la pregunta ahora es, usted solicita un recurso en http, que le devuelve un 403 con algún script java que ayuda a poner https en la url para usted y, por lo tanto, emitir una nueva solicitud https. No es un 301/301 inducido por HTTPS. Puede ser el título de la pregunta que dice la palabra redireccionar, pero ahora tengo dudas sobre el nombre inapropiado ahora. Para poner las cosas en perspectiva, aquí hay una publicación - enlace que describe que estoy diciendo. Muy viejo post de hecho. ¿Cómo es esto una pregunta duplicada?

    
pregunta gmaran23 08.01.2014 - 18:05
fuente

1 respuesta

1

Hacer esto en el navegador con JavaScript es inseguro e ineficiente.

Como ya ha mencionado, si el agente de usuario no ejecuta JavaScript, entonces el usuario simplemente se sentará en su página 403 Prohibida. Si va a devolver una respuesta 403 a un usuario, ¿por qué no devolver un 301 y hacer un uso de la respuesta? En el mejor de los casos, esta es una mala experiencia para el usuario y las personas que ingresan a la URL de su http se redirigen en lugar de la https.

Desde un punto de vista de seguridad, estás abriendo al usuario a los ataques de un MiTM. Si el usuario escribe en site.com sin especificar un protocolo, el navegador usará HTTP de manera predeterminada y hará una solicitud a enlace para ellos. Si la redirección se realiza en JavaScript, el navegador no lo recordará. Si el servidor responde con un redireccionamiento permanente 301 a enlace , el navegador guardará esta respuesta en caché. La próxima vez que el usuario escriba en site.com, el navegador visitará enlace en lugar de enlace como antes. Esto ayuda a mitigar varias formas de ataques de supresión de SSL pero no es la solución perfecta. Aún así, es un poco más seguro.

Lo que también podría hacer es emitir una política de HSTS para su dominio. He explicado en detalle qué es HSTS en mi blog titulado " HSTS: el eslabón perdido en la seguridad de la capa de transporte ". En pocas palabras, HSTS le permite indicar a un navegador que siempre use https sin necesidad de redireccionar. Aún necesita mantener las redirecciones para los agentes de usuario que no cumplen con las normas, pero es otro paso en la dirección correcta.

    
respondido por el Scott Helme 08.01.2014 - 19:02
fuente

Lea otras preguntas en las etiquetas