La publicación del blog de Paul Moore retiene mucha información, probablemente a propósito, ya que asda no solucionó el problema cuando publicó la publicación.
Aquí hay un artículo que es un poco más explícito sobre las vulnerabilidades de Asda .
Vulnerabilidad de CSRF
En primer lugar, parece que no tenían ninguna protección CSRF:
No hay protección XSRF en todo el sitio. Es posible secuestrar de forma remota cualquier cuenta activa sin saber el nombre de usuario / contraseña
El impacto de esto depende de lo que realmente puede hacer un usuario en el sitio web (porque eso es lo que un atacante también puede hacer con CSRF, excepto si un usuario tiene que ingresar una contraseña para la acción). Por la descripción, no suena como si fuera demasiado:
También es posible agregar / eliminar elementos de la cesta desde un sitio remoto y enviarlos a una dirección alternativa, lo que aumenta el riesgo de fraude / robo de identidad.
Esto obviamente es malo, sin embargo.
CSRF a XSS
En el exploit, va a otro sitio con la carga maliciosa en otra pestaña, y al volver a la página ASDA aparece un formulario solicitando la información de la tarjeta de crédito que su servidor ve cuando se envía.
No pude encontrar ninguna información sobre esto, pero una apuesta segura es que se trata de un problema de XSS persistente a través de CSRF (o tal vez reflejado POST XSS a través de CSRF).
Lo que probablemente esté sucediendo: algún campo de formulario en el sitio web es vulnerable a XSS a través de POST, ya sea reflejado o persistente, y esto puede ser explotado porque no hay protección CSRF.
Normalmente, los problemas de POST XSS en un área de usuarios no serían un problema tan grande (aunque todavía no debería tenerlos), ya que la protección CSRF (y posiblemente ClickJacking) impide que las personas lo exploten (si el inicio de sesión es también CSRF protegido).
Pero como no hay protección CSRF, la vulnerabilidad XSS en el área del usuario ahora es explotable. Como XSS es un poco más poderoso que CSRF, esto es un problema.
El código de ataque podría tener este aspecto (está hecho para ilustrar el punto):
<form action="https://example.com/profile.php" method="POST" id="myform">
<input type="hidden" name="name" value="<script>alert(1)</script>" />
<input type="submit" value="Submit request" />
</form>
<script>document.myform.submit();</script>
Si un usuario visita un sitio web que contiene este código mientras está conectado a asda, su perfil se actualizará y el código inyectado se ejecutará en el contexto del sitio asda.
Como puede ver, la carga de XSS en el ejemplo es enviada por la víctima, lo que significa que el filtrado del navegador probablemente protegerá a algunos usuarios. Sin embargo, es probable que un atacante pueda crear una nueva cuenta, inyectar la carga útil en esa cuenta y luego forzar el inicio de sesión de una víctima a través de CSRF, sin pasar por el filtrado del navegador. Si una víctima no se da cuenta de que ha iniciado sesión en una cuenta diferente, todavía puede proporcionar información confidencial.