¿Una redirección 302 mantendrá la cadena de referencia?

92

Necesito redirigir al usuario de una página a otra, pero necesito mantener la cadena de referencia original. Entonces, por ejemplo, si comienzan en http://www.othersite.com/pageA.jsp , haga clic en un enlace que los lleve a http://www.example.com/pageB.jsp , que luego ejecuta un 302 redirigir a http://www.example.com/pageC.jsp , necesito que la cadena de referencia contengahttp://www.othersite.com/pageA.jsp

¿Es este el comportamiento normal de una redirección 302? ¿O mi referidor original sería descartado a favor de http://www.example.com/pageB.jsp? Eso no sería deseable.

No sé si hace alguna diferencia, pero estoy trabajando en JSP y estoy usando response.sendRedirect()para ejecutar la redirección 302.

Debo mencionar que hice un experimento con esto, y parece haber mantenido la cadena de referencia original ( http://www.othersite.com/pageA.jsp) pero solo quería asegurarme de que este fuera el comportamiento predeterminado normal, y no algo extraño por mi parte.

Aunque actualmente estoy usando una redirección 302, probablemente podría usar una redirección 301 en su lugar. ¿Sabe si el comportamiento de las redirecciones 301 es más confiable?

jsp redirect referrer http-status-code-302 http-referer sangre fría
fuente
3
Solo necesito lo contrario. Realice una redirección del lado del servidor cambiando la referencia en la redirección (por lo que elimine la referencia original) ¿Nadie?
cprcrack

Respuestas:

32

La respuesta corta es que no se especifica en el RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 relevante ni para el encabezado Referer ni para el código de estado 302.

Su mejor opción es hacer una prueba con varios navegadores y ver si hay un comportamiento de consenso.

Para el cinturón completo y los tirantes, codifique la referencia original en la URL de redireccionamiento para que pueda garantizar su recuperación.

Caja Malcolm
fuente
19
A quien le pueda interesar, hice pruebas spme en los principales navegadores: stackoverflow.com/questions/2158283/…
Marco Demaio
121

No sé sobre el 302, pero probé el 301 en algunos navegadores hoy, aquí están los resultados:

ESCENARIO : el usuario hace clic en el enlace de dominioX que apunta a dominioA. domainA realiza una redirección 301 a domainB.

  • IE8 referercuando aterriza en dominioB es: dominioX (incluso cuando se usa la navegación InPrivate e incluso cuando el usuario abre el enlace en una nueva pestaña)
  • Safari4 referercuando aterriza en el dominioB es: dominioX (incluso cuando el usuario abre el enlace en una nueva pestaña)
  • FF3.6.10 referercuando aterriza en dominioB es: dominioX (incluso cuando el usuario abre el enlace en una nueva pestaña)
  • Chrome5 referercuando aterriza en dominioB es: dominioX (a menos que el usuario abra enlaces en una nueva pestaña)
  • Chrome26 referercuando aterriza en el dominioB es: dominioX (incluso cuando el usuario abre enlaces en una nueva pestaña)
Marco Demaio
fuente
27
Nota: esta prueba se realizó hace un tiempo, y hoy en día Chrome 26 se comporta de la misma manera incluso cuando se abre en una nueva pestaña .
Benjamin
No probado en todos los navegadores, pero el comportamiento de 302 parece ser idéntico.
Amir Ali Akbari
1
Nota: si la página de redireccionamiento (dominioA) emite una Política de referencia: encabezado sin referencia , Chrome (y Opera) no establecerá el encabezado de referencia en la solicitud en la página de destino (dominioB). Firefox y Edge todavía lo envían.
David Balažic
12

Buena pregunta. En este caso, el envío del remitente depende completamente del navegador (porque se le dice al navegador que haga otra solicitud al nuevo recurso).

RFC 2616 permanece en silencio sobre el problema:

El recurso solicitado reside temporalmente en un URI diferente. Dado que la redirección puede modificarse en ocasiones, el cliente DEBE continuar utilizando Request-URI para solicitudes futuras. Esta respuesta solo se puede almacenar en caché si se indica mediante un campo de encabezado Cache-Control o Expires.

No confiaría en que el navegador envíe el referente correcto. Apuesto a que hay al menos uno que envía algo diferente a los demás.

Solución alterna

Si puede, ¿por qué no agregar un ?override_referer=<old_url>parámetro a la URL a la que redirige y analizar ese valor en lugar de HTTP_REFERER?

De esa manera, puede estar seguro de obtener siempre el resultado correcto y no perder nada en seguridad: el árbitro puede ser falsificado de cualquier manera.

Pekka
fuente
4
De hecho, está perdiendo algo de seguridad al hacer que el referente se pueda anular en la URL. En la mayoría de los navegadores modernos, el referente para las solicitudes AJAX no se puede cambiar mediante JavaScript; sin embargo, la URL obviamente puede hacerlo. Esto significa que en el caso de un ataque XSS, el referente es más confiable que el parámetro URL. No me malinterpretes, el referente sigue siendo claramente una entrada del usuario en la que no se puede confiar completamente. Pero es mucho más difícil falsificar esos datos para otra persona que cambiar la URL.
phylae
7

Tuve el problema opuesto: quería que el referente fuera "pageB" pero ninguno de los navegadores actuales procede de esta manera ...

Así que probé con una redirección HTML en la página B (en lugar de la redirección 301 o 302):

<meta http-equiv="refresh" content="0; url=pageC.jsp" />

Y el resultado fue sorprendente:

  • Referer es pageB con Chrome
  • ¡Referer está VACÍO con FireFox e IE!

Espero que esto pueda ayudar

fred727
fuente