Cómo justificar que un XSS almacenado que se produce después de iniciar sesión es una vulnerabilidad

El equipo de desarrollo está equivocado. El impacto aquí es la escalada horizontal y vertical de privilegios.

La XSS posterior a la autenticación es tan válida como la XSS previa a la autenticación. En general, desea que la víctima se registre de todos modos, ya que desea explotar su autenticación actual. El único factor atenuante es que el atacante requiere una cuenta. Dependiendo de lo fácil que sea conseguirlo, el índice de impacto del problema bajará, pero sigue siendo una vulnerabilidad [*]

Un atacante puede usar XSS para realizar acciones arbitrarias en nombre de cualquier usuario que visite la página que contiene la carga útil, y leer cualquier información a la que tengan acceso esos usuarios.

_{[*] Tenga en cuenta que para algunos usuarios esto puede ser un riesgo aceptado. Algunas aplicaciones, por ejemplo, permitirían a los administradores publicar HTML sin filtrar, ya que ya tienen acceso ilimitado sin XSS.}

_{Si la carga útil solo se mostraría al usuario que la inserta, eso sería un problema diferente. Solo podría explotarlo haciendo que el usuario ingrese los datos (por ejemplo, mediante clickjacking o CSRF) o engañando al usuario para que inicie sesión en la cuenta que colocó la carga útil (por ejemplo, a través de la fijación de sesión o CSRF de inicio de sesión).}

Crea un script que cuelgue las aplicaciones y deja que se ejecute para todos los usuarios que hayan iniciado sesión.

Si desea realizar ataques más avanzados, inserte un script que llame a una API para cambiar la información del perfil de un usuario u otros datos (ya que su script tendrá acceso a las cookies para que pueda realizar cualquier llamada a ese dominio que se basa en en las cookies para la autenticación). También puede obtener la información del perfil del usuario y mostrarla en la pantalla (para demostrar que el atacante puede obtener acceso a todos estos datos).

Otro paso más sería mostrar una IU que solicite el nombre de usuario y la contraseña (con algún mensaje como "su sesión ha expirado, ingrese el nombre de usuario y la contraseña para continuar"), y no permite que el usuario continúe usando el la aplicación hasta que haya verificado que la contraseña es correcta (por ejemplo, contra algún punto final de autenticación). No tiene que almacenarlo en ningún lugar, simplemente está indicando que, en este punto, el escritor del script puede enviar la contraseña a su propio servidor.

La cantidad de esto que tendrá que construir dependerá de la cantidad de convenciones que deba hacer. También puedes hacerles saber que estás siendo amable al decirles que estás haciendo esto, un usuario malintencionado no tiene que decírselo.

Si la aplicación está abierta para cualquier usuario (es decir, cualquiera puede registrarse) y lleva a cabo el ataque, simplemente registre a un nuevo usuario con un nombre críptico y demuéstrelo.

Si los usuarios registrados son solo empleados internos, entonces se reduce a la confianza entre los empleados. Amenaza interna es una preocupación muy legítima.

La única buena defensa es una defensa en profundidad. Por el momento, su esquema de autenticación puede parecer seguro. Pero algún día se encontrará una vulnerabilidad en él, ya sea por un atacante, o por usted, o por un experto descontento que ya está autenticado.

Si estuvieran ejecutando la defensa adecuada en profundidad, entonces cuando ese agente hostil accediera al sistema, el daño que podrían hacer estaría limitado por otros mecanismos de seguridad. Sin embargo, con su actitud de que una vulnerabilidad solo cuenta si puede ser ejecutada por una amenaza externa, están desperdiciando completamente cualquier oportunidad para crear líneas de defensa adicionales.

Entonces, por ejemplo, un atacante que solo podía obtener acceso limitado de usuarios podía obtener credenciales de administrador. Su esquema de autorización es vulnerable. O un empleado mal pagado podría decidir administrar un minero de criptomoneda basado en JS en los clientes de todos sus usuarios para ganar un poco de dinero extra adicional. O un usuario externo a finanzas / administración podría acceder a información interna para un poco de información privilegiada.

Decir XSS no importa porque tienes que iniciar sesión es funcionalmente equivalente a decir que todos los usuarios registrados deben tener permiso para ver y hacer todo lo que hacen los demás usuarios registrados. No hay usuarios ni administradores, ni privacidad departamental, ni usuario no repudio. Todos los usuarios, funcionalmente indistinguibles. Si eso no es cierto para su caso de uso, entonces XSS es una vulnerabilidad explotable que debería preocuparle.

Editar: Si están convencidos de que nada de lo anterior podría suceder, te recomiendo cambiar a los ataques de ingeniería social en el esquema de autenticación. Los esquemas de autenticación más seguros aún requieren interacción humana y, por lo tanto, son deprimentemente vulnerables.