Senza uno screenshot dei risultati è impossibile dirlo con certezza, ma suona con una sicurezza del 99,999% che la destinazione non sia vulnerabile a XSS. Congratulazioni allo sviluppatore!
Se stai cercando un modo per praticare l'esecuzione di XSS, potresti prendere in considerazione la creazione di una tua applicazione vulnerabile (privata). Un campo di input con input senza escape dovrebbe fare bene il trucco. Ci sono anche una serie di siti e giochi che sono intenzionalmente vulnerabili come strumento di apprendimento, per permettere alle persone di esercitarsi nell'esecuzione di XSS.
Infine, riguardo a questo:
Does the payload just get displayed because it's first encrypted to that token and not sent?
Penso che tu stia davvero pensando troppo a questo. Non credo che la criptazione abbia un ruolo in questo caso - piuttosto, il punto critico è se il tuo input è o meno sfuggito. (Sicuramente cerca di sfuggire se non hai familiarità con esso.) L'input senza escape è sempre una responsabilità, sia che venga ricevuto come testo in chiaro che non è mai stato crittografato, né come testo cifrato decrittografato. L'applicazione lo vede allo stesso modo.
Inoltre, nessuno qui in Internet Land è in grado di rispondere definitivamente a questa domanda, dal momento che non conosciamo l'applicazione o la sua architettura. Bella domanda, e penso che tu sia sulla strada giusta: hai ragione che qualcosa viene trasformato da JavaScript in modo che non possa essere eseguito. L'unica differenza è che la trasformazione che rende l'input sicuro e non eseguibile è l'escape piuttosto che la crittografia *.
* Sebbene sia importante notare che sì, anche rappresentando JavaScript senza caratteri escape, il testo cifrato non può essere eseguito poiché rappresenta solo JavaScript e non è esso stesso JavaScript senza le chiavi di decrittazione necessarie.
