Soy nuevo aquí en seguridad.

Quiero identificar a los usuarios sospechosos en la aplicación web mediante el análisis del archivo de registro de acceso web. Para esto, estoy considerando el ataque CSRF.

Para este propósito, estoy generando algunas reglas heurísticas (posibles) para la identificación de usuarios sospechosos desde el registro web. No estoy seguro, pero todavía adiviné algunas reglas,

En el registro web,

1. La URL de referencia está en blanco o no es igual al nombre de dominio de la URL solicitada.

para, por ejemplo,

192.168.4.6 ­ ­ [10/Oct/2007:13:55:36 ­0700] "GET /trx.php? amt=100&toAcct=12345 HTTP/1.0" 200 4926
"http://www.attacker.com/freestuff.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"

Aquí hay dos campos importantes, la URL solicitada ( /trx.php? amt=100&toAcct=12345 ) y el referente (" http://www.attacker.com/freestuff.php "). Generalmente, el referente es una URL del mismo sitio ( www.bank.com ). Aquí hay un ejemplo de fragmento de código, cómo podría detectarse:

# assuming $referer is set with the, well, referer
if ( ( $referer ne '­' ) && ( $referer !~ /^https?:\/\/www.bank.com\/(login|overview|trx)\.jsp/ ) ) 
{
    # handle XSRF attack
    print(“XSRF attack: $referer\n”);
}

2. Si el estado de HTTP es 403 , es decir, acceso denegado

(Si no se envía el token CSRF, o si se envía un token CSRF no válido en solicitudes que requieren un token CSRF). Entonces, aquí se incluirá la verificación del estado 403. Debido a que el token no se puede comprobar en el archivo de registro.

3. Midiendo la diferencia horaria de las solicitudes de un usuario.

Si no hubo ninguna entrada por parte del usuario durante varios minutos y luego, de repente, llegan algunas solicitudes de transferencia, podría ser un indicador de que esta solicitud fue activada por algo / otra persona. Aquí, será necesario verificar la diferencia de tiempo hasta el valor de umbral desde la misma dirección IP. (Junto con esto, si hay valores presentes después del símbolo ? y estos serían 'pasar', 'contraseña', 'cantidad', 'amt', 'dinero', o cualquier enlace y si el estado de la solicitud del Usuario fuera 200, es decir, exitoso o OK).

4. Solicitud múltiple POST (repetición) desde una sola dirección IP también    resultados en CSRF.

Métodos idempotentes y aplicaciones web. Los métodos PUT y DELETE se definen como idempotentes, lo que significa que varias solicitudes idénticas deben tener el mismo efecto que una sola solicitud (tenga en cuenta que idempotente se refiere al estado del sistema después de que la solicitud se haya completado, de modo que la acción que realiza el servidor (por ejemplo, eliminar un registro) o el código de respuesta que devuelve puede ser diferente en las solicitudes posteriores, el estado del sistema será el mismo cada vez que [cita requerida]). Los métodos GET, HEAD, OPTIONS y TRACE, que se prescriben como seguros, también deben ser idempotentes, ya que HTTP es un protocolo sin estado.

En contraste, el método POST no es necesariamente idempotente y, por lo tanto, enviar una solicitud POST idéntica varias veces puede afectar aún más el estado o causar otros efectos secundarios (como transacciones financieras). En algunos casos, esto puede ser deseable, pero en otros casos puede deberse a un accidente, como cuando un usuario no se da cuenta de que su acción dará lugar al envío de otra solicitud, o no recibió una respuesta adecuada de que su primera solicitud fue exitoso. Si bien los navegadores web pueden mostrar cuadros de diálogo de alerta para advertir a los usuarios en algunos casos en los que la recarga de una página puede volver a enviar una solicitud POST, generalmente depende de la aplicación web manejar los casos en que una solicitud POST no debe enviarse más de una vez. / p>

5. Un sitio web puede permitir la eliminación de un recurso a través de una URL como     http://example.com/article/1234/delete , que, si es arbitrariamente    recuperado, incluso usando GET, simplemente eliminaría el artículo. (No sé qué hacer aquí)

Lo sé, la identificación de CSRF a partir del archivo de registro es difícil, por lo que menciono posibles formas (es decir, heurísticas) aquí. Si está equivocado, se requiere corrección en esto. Cualquier otra regla / ayuda sería apreciada.