Detección de anomalías en HTTP REFERER

1

Estoy tratando de poner un poco de detección anomólica en lugar y estoy mirando datos de referencia (sé que esto es opcional, y puede ser falsificado en algunas circunstancias). Pero estoy viendo demasiados casos de lo que creo que son falsos positivos.

De rfc2616 :

The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained

Entiendo que esto significa que el remitente debe completarse solo cuando la solicitud se genera desde un enlace, envío de formulario, solicitud ajax o contenido relacionado explícitamente que contiene la URL de destino. es decir, si el usuario navega a mi sitio utilizando un marcador, una dirección ingresada manualmente o mediante otro sitio de la página (sin tener en cuenta la posibilidad de que esto pueda generar un redireccionamiento 30x), entonces no debería ver la página en la que se encontraban anteriormente.

Pero veo una gran cantidad de casos en los que la URL proporcionada como remitente no tiene un enlace a mi sitio. Además, muchas de estas referencias son operaciones acreditadas (incluidos los grandes bancos) que deberían estar protegidas contra ataques de tipo XSS, por lo que es poco probable que los casos que veo se deban a que el usuario acceda a una página modificada.

Soy consciente de que hay problemas pendientes desde hace mucho tiempo en iPads y iPhones (CVE-2009-2797, CVE-2008-3171) que dan lugar a este comportamiento (antes de que empecé a filtrarlos, ipads e iphones estaban representados de manera desproporcionada en la salida) sin embargo, estoy viendo estas rarezas para MSIE, Firefox y 26, y muy ocasionalmente Google Chrome.

No he podido replicar el comportamiento en Firefox (la misma versión que se informa en mis datos de producción) usando

  • un href simple (el referente es la página anterior)
  • un formulario (tanto GET como POST) (el referente es la página anterior)
  • un cambio a window.location via javascript (el referer es la página anterior)
  • un img ref (el referente es la página anterior)
  • marcador (sin referencia)
  • ubicación ingresada manualmente (sin referencia)

No he mirado los scripts tipo Greasemonkey. ¿Alguien puede recomendar si esto dará lugar a este comportamiento? No veo ninguna evidencia de pre-vuelo que implicaría un CORS.

¿Hay algo más que me esté perdiendo?

    
pregunta symcbean 10.01.2014 - 14:42
fuente

2 respuestas

1

Es un método común de spam (SEO) para dar referencias falsas con la esperanza de aparecer en algún lugar u otro, esto podría explicar algunas de las entradas.

    
respondido por el freddyb 10.01.2014 - 20:15
fuente
0

Si una página web no se vincula directamente a su página web, sino que envía a los usuarios a través de un script de redirección que redirige a los usuarios con un código de estado 301 Movido permanentemente , la referencia será la página en la que se encontraba el enlace en lugar del script .

Por ejemplo, considere el siguiente escenario:

Página 1

Esta es una página que enlaza con su sitio a través de un script de redirección.

(…)<a href="/redirect.php?goto=your_site_url">Your Site</a>(…)

Página 2

Este es el script de redireccionamiento. Podría ser tan simple como:

<?php if(!isset($_GET['goto'])) die("No redirect URL found");
  header('HTTP/1.1 301 Moved Permanently');
  header('Location: '.$_GET['goto']);//You should not do this in your application: http://websecurity.com.ua/3386/ https://www.owasp.org/index.php/HTTP_Response_Splitting https://www.owasp.org/index.php/Open_redirect
  die("Moved <a href='".$_GET['goto']."'>Here</a>.");//This is a bad idea as well: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
?>

Ahora, si un usuario hace clic en el enlace en la página 1, se lo enviará a su sitio a través del script de redirección, pero con la página con el enlace como el Referente [sic].

    
respondido por el user2428118 10.06.2014 - 11:28
fuente

Lea otras preguntas en las etiquetas