Resultados de Pentest: Ataque CSRF cuestionable

Question

Resultados de Pentest: Ataque CSRF cuestionable

#1 de tim (46 votos)
#2 de Sjoerd (12 votos)
#3 de Michal Koczwara (2 votos)

26

Recientemente hemos tenido una de nuestras aplicaciones web saturadas. Todo salió bien, a excepción de una vulnerabilidad CSRF, y es este descubrimiento el que tengo un hueso para elegir.

Algunos antecedentes: estamos usando ASP.NET MVC y, entre otras cosas, usamos funcionalidad CSRF integrada en ella. La forma en que funciona es estrictamente de acuerdo con lo que OWASP recomienda por incluyendo los llamados "tokens de sincronizador", uno en una cookie HTTP y otro en una entrada oculta llamada __RequestVerificationToken :

<form action="/Home/Test" method="post">
  <input name="__RequestVerificationToken" type="hidden" 
    value="6fGBtLZmVBZ59oUad1Fr33BuPxANKY9q3Srr5y[...]" />    
  <input type="submit" value="Submit" />
</form>

También realizamos exploraciones regulares de Acunetix y dijimos que las exploraciones nunca encontraron ningún formulario sin protección CSRF.

Ahora, lo que afirman los pentesters es que pudieron "violar" nuestra protección CSRF con el siguiente código:

<html>
  <body>
    <form action="https://our.site/support/discussions/new" method="POST">
      <input type="hidden" name="subject" value="Subject" />
      <input type="hidden" name="content" value="Content" />

      <input type="hidden" name="__RequestVerificationToken" 
        value="_e-upIZFx7i0YyzrVd[...]" />

      <input type="submit" value="Submit Request" />
    </form>
  </body>
</html>

La inclusión del campo __RequestVerificationToken es lo que más me molesta: para mí, es como afirmar que un atacante ha transferido millones de dólares de mi cuenta bancaria porque voluntariamente le di mi iPhone para que juegue con él, y él vi la contraseña de un solo uso que mi banco envió en un SMS.

Me imagino que la única forma en que este ataque podría funcionar es si no estuviéramos usando HTTPS, fuera vulnerable a XSS, usáramos cookies no solo de HTTP y fuéramos negligentes con una Política de Same Origin. Nada de lo cual es cierto, ya que ninguna de estas vulnerabilidades fue reportada por Pentesters o Acunetix.

Entonces la pregunta es: ¿estoy equivocado y esto es una vulnerabilidad legítima de CSRF o no?

penetration-test csrf

pregunta Anton Gogolev 23.11.2016 - 08:48

fuente

3 respuestas

Lea otras preguntas en las etiquetas penetration-test csrf

¿Qué tan práctico es aplicar una fuerza bruta a un número de 10 dígitos a través de la URL? ¿Sha1sum sigue siendo seguro para la firma de paquetes de software descargables?

score 46 · Answer 1

Esto no parece ser una vulnerabilidad CSRF.

Si un atacante necesita conocer un token CSRF, no es un ataque. Y su enfoque de CSRf parece ser correcto.

Los problemas que filtran el token de CSRF pueden provocar un ataque de CSRF, pero el problema no es una protección de CSRF incorrecta, sino esos problemas (XSS, cifrado, token de CSRF en la URL, etc.).

Aún así, le pediría al probador una aclaración. Quién sabe, tal vez el ataque siempre funciona con ese token específico, porque está codificado en algún lugar, o porque los caracteres especiales están causando algún tipo de problema para su aplicación. O tal vez es posible usar un token de un usuario diferente, o tal vez la verificación del token simplemente no funciona y acepta tokens arbitrarios. El informe debería haber contenido más detalles, por lo que consultaría con el evaluador acerca de esto.

score 12 · Answer 2

De hecho, es extraño que el __RequestVerificationToken esté incluido en la prueba de concepto, ya que normalmente un atacante no sabría el valor de este token.

Sin embargo, la página aún puede ser vulnerable a CSRF si el __RequestVerificationToken no está enlazado correctamente a la sesión. Si el valor en la prueba de concepto, _e-upIZFx7i0YyzrVd[...] , funciona para todos, usted es vulnerable a CSRF. Si solo funciona para el usuario en el que se registró el pentestro, no eres vulnerable a CSRF.

Ya que está usando la protección por defecto .NET CRSF, asumiría que esto se implementa correctamente y que el pentester ha cometido un error.

score 2 · Answer 3

2

Si __RequestVerificationToken no se valida en el lado del servidor y si funciona para cada solicitud individual y usuario diferente, sí, su aplicación es vulnerable a CSRF.

respondido por el Michal Koczwara 23.11.2016 - 10:04

fuente