prevención CSRF en PHP

Navega tus respuestas
6

Dos preguntas.

  1. ¿Dónde se descarga la versión PHP de CSRF Guard de OWASP? La siguiente URL dice que compruebes Git:

    enlace

    Todo lo que veo en Git son los archivos * .java y los archivos * .js. Si hay archivos PHP, ¿dónde están en la estructura del directorio?

  2. phpBB previene CSRF agregando dos parámetros ocultos a todas las formas. El tiempo y un hash SHA1 del tiempo, un "formulario salt" por usuario, el identificador de sesión y el nombre del formulario. Fuente:

    anexo

    Mi pregunta es ... ¿por qué es necesaria otra cosa que no sea la sal de forma? Para evitar el CSRF, todo lo que necesita es una cadena aleatoria que un atacante no puede predecir, por lo que no puede enviar una solicitud HTTP a ciegas y el formulario salt haría el truco que me parece. Hashing que junto con todo lo demás simplemente parece innecesario.

    Tal vez su motivación es que la forma de sal podría verse comprometida si alguien copia / pega el contenido HTML de la página. ¿Tal vez está destinado a probarlo en el futuro? Una vulnerabilidad XSS comprometería permanentemente las protecciones CSRF si la sal de formulario se usara directamente mientras que con un hash de tiempo y la sal de forma protege contra ese escenario.

    Además, si la sal era solo de dos caracteres o algo así, podría entender hacer el hash sha1 () pero una sal de dos caracteres es simplemente insegura porque todo lo que necesita hacer en ese momento es enviar 256 ** 2 solicitudes HTTP ciegas , cada uno con un token diferente. Pero tampoco es de dos caracteres.

pregunta compcert 02.02.2012 - 08:19
fuente

2 respuestas

2

  1. Curioso, pero no eres el primera persona para preguntar al respecto , e incluso hay una implementación sugerida para la protección CSRF allí + el código alojado en github . Sin embargo, realmente no puedo responder por este mecanismo, no lo he inspeccionado demasiado de cerca.

  2. Pregunta interesante. Me parece que phpbb fue un poco exagerado con la implementación, pero hay algo de lógica detrás. La sal sola no sería suficiente, porque en el caso de phpbb, el valor user_form_salt es un valor estático por usuario, que no cambia para ese usuario en particular. Esto significa que una vez que se conoce / divulga este valor (y es probable que haya muchas maneras de filtrar u obtener este valor), entonces todos los formularios de usuario pueden verse comprometidos. Para siempre (o más precisamente por la duración de esta sal, pero normalmente no cambia). El método implementado allí tiene la ventaja de que el valor cambia constantemente, pero el servidor lo puede reproducir para verificarlo sin tener que almacenarlo en ningún lugar. Utiliza datos almacenados existentes + algunos elementos aleatorios para generar el token CSRF. No estoy muy seguro, pero supongo que usarlo, por ejemplo. El hash / HMAC del tiempo con alguna variable de sesión aleatoria interna (no expuesta) como clave, lograría el mismo resultado.

Por último, solo una breve nota sobre su comentario con respecto a XSS y CSRF. Dijiste que

  

Una vulnerabilidad XSS comprometería permanentemente las protecciones CSRF si la sal de formulario se usara directamente mientras que con un hash de tiempo y la sal de forma protege contra ese escenario.

Básicamente, una vulnerabilidad XSS puede comprometer la protección de CUALQUIER CSRF. Si el atacante puede ejecutar código con la sesión del usuario, tiene acceso a todos los datos del formulario, por muy bien protegido que esté.

    
respondido por el Yoav Aner 02.02.2012 - 20:55
fuente
0

Respuesta para la primera parte:

La versión php de OWASP CSRF Guard se ha implementado como OWASP CSRF Protector (el nombre del proyecto se cambió debido a la diferencia en lógica de diseño). Está disponible en github para descargar!

    
respondido por el mebjas 13.12.2014 - 18:52
fuente

Lea otras preguntas en las etiquetas

Lista de correo de anuncios de seguridad para Java Seguridad de Haskell y Happstack