¿Se considera una amenaza de seguridad inyectar una segunda autenticidad en una solicitud de inicio de sesión?

Question

¿Se considera una amenaza de seguridad inyectar una segunda autenticidad en una solicitud de inicio de sesión?

#1 de SilverlightFox (1 votos)
#2 de Aatif Shahdad (1 votos)

0

Estoy ejecutando una prueba de seguridad en un sitio web. La solicitud de inicio de sesión se ve así:

    POST /sessions HTTP/1.1
    Host: example.com
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
    Accept-Language: en-GB,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: https://example.com/login/
    Cookie: guest_id=v13A143119700248937739; ga=GA1.2.2044559433.1430765006; eu_cn=1; kdt=EYxSZrzMFf9mQfhszqmTBvqOPw9yKfSG1APJHsxj; sess=BAh7CiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCCAI%252FD5NAToMY3NyZl9p%250AZCIlNDNiN2I5NWEyYzdkY2IyODNiNTI2MjJmN2E4OGUzYzU6B2lkIiVjZGM4%250AZDVlNjk2ZmZiOTUyMTQxNjE2YjFjYTU3NWFjODoJdXNlcmwrB%252BEaIKw%253D--472855fe8d2a70f4327cac502e1d1e916dc0d52f;
    Connection: keep-alive
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 239

session%5Busername_or_email%5D=bugtest3000%40gmail.com&session%5Bpassword%5D=badpassword&authenticity_token=326c4ad687f74a52359710bad94a2bfce9e4d9d6

Puedo inyectar un segundo authenticity_token y seguir iniciando sesión. ¿Es este un problema de seguridad?

        POST /sessions HTTP/1.1
        Host: example.com
        User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
        Accept-Language: en-GB,en;q=0.5
        Accept-Encoding: gzip, deflate
        Referer: https://example.com/login/
        Cookie: guest_id=v13A143119700248937739; ga=GA1.2.2044559433.1430765006; eu_cn=1; kdt=EYxSZrzMFf9mQfhszqmTBvqOPw9yKfSG1APJHsxj; sess=BAh7CiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCCAI%252FD5NAToMY3NyZl9p%250AZCIlNDNiN2I5NWEyYzdkY2IyODNiNTI2MjJmN2E4OGUzYzU6B2lkIiVjZGM4%250AZDVlNjk2ZmZiOTUyMTQxNjE2YjFjYTU3NWFjODoJdXNlcmwrB%252BEaIKw%253D--472855fe8d2a70f4327cac502e1d1e916dc0d52f;
        Connection: keep-alive
        Content-Type: application/x-www-form-urlencoded
        Content-Length: 239

session%5Busername_or_email%5D=bugtest3000%40gmail.com&session%5Bpassword%5D=badpassword&&scribe_log=&redirect_after_login=%2F&authenticity_token=326c4ad687f74a52359710bad94a2bfce9e4d9d5&authenticity_token=11111111111111111111111111111111111111111111

authentication token csrf ruby

pregunta Mico 12.05.2015 - 13:17

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication token csrf ruby

¿Secuestrar conexiones SSL / TLS atacadas? cómo detectar la URL que usa una aplicación de Android [duplicar]

score 1 · Answer 1

Esto no es una vulnerabilidad como se muestra, ya que el sistema simplemente toma el valor del primer parámetro.

Una vulnerabilidad de HTTP Parameter Pollution (HPP) es cuando se puede usar el comportamiento de la aplicación a alguna ventaja.

Por ejemplo, en mi respuesta aquí se inyecta un parámetro toAccount :

amount=1000&fromAccount=12345&toAccount=99999

Esto se conoce como Inyección de parámetros HTTP (HPI).

Esto produce una vulnerabilidad de HPP en la solicitud de servicio de fondo:

toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999

a medida que el sistema en el ejemplo toma el segundo toAccount y redirige la transferencia bancaria al atacante.

Si no puede utilizar esta vulnerabilidad de HPP en su beneficio, entonces no es una vulnerabilidad. Intenta cambiar el orden de los parámetros o ve si el token se usa en otro lugar donde puedas aprovechar esto para utilizarlo en un ataque.

score 1 · Answer 2

Creo que este ataque si se llama con éxito como HTTP Parameter Pollution(HPP) y la capacidad de inyectar parámetros se llama HTTP Parameter Injection . Más sobre eso en: https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_%28OTG-INPVAL-004%29

Ahora, en lo que respecta al escenario que describió, según mi experiencia, muchos servidores le permitirán enviar múltiples parámetros con el mismo nombre, como su 'autenticidad_título'. Algunos servidores utilizan la primera instancia del valor en la solicitud y algunos usan la última según el servidor. Creo que el servidor en su caso podría estar utilizando el primer valor . Pero, para verificar más y determinar su explotabilidad, citando el enlace de OWASP anterior:

Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities.

Creo que esto lo explica bien. Espero que haya ayudado.