Sin una captura de pantalla de sus resultados, es imposible decirlo con certeza, pero suena con una confianza del 99,999% de que el objetivo no es vulnerable a XSS. Felicidades al desarrollador!
Si está buscando una manera de practicar la ejecución de XSS, podría considerar crear su propia aplicación vulnerable (privada). Un campo de entrada con entradas no escapadas debe hacer el truco muy bien. También hay una serie de sitios y juegos que son intencionalmente vulnerables como herramienta de aprendizaje, para que las personas practiquen la ejecución de XSS.
Finalmente, respecto a esto:
¿La carga útil solo se muestra porque primero se cifra a ese token y no se envía?
Creo que en realidad estás pensando demasiado. No creo que la encriptación juegue un factor aquí, más bien, la parte crítica es si tu entrada se escapa o no. (Definitivamente busque escape si no está familiarizado con él). La entrada no escapada es siempre una responsabilidad, ya sea que se reciba como texto plano que nunca se ha cifrado o como texto cifrado descifrado. La aplicación lo ve de la misma manera.
Además, nadie aquí en Internet Land puede responder esta pregunta de manera definitiva, ya que no conocemos la aplicación ni su arquitectura. Sin embargo, es una buena pregunta y creo que estás en el camino correcto: estás en lo cierto al decir que algo se está transformando de JavaScript para que no se pueda ejecutar. La única diferencia es que la transformación que hace que la entrada sea segura y no ejecutable está escapando en lugar de encriptación *.
* Aunque es importante tener en cuenta que sí, incluso representando JavaScript no escapado, el texto cifrado no se puede ejecutar ya que solo representa JavaScript y no es JavaScript en sí mismo sin las claves de descifrado necesarias.
