The “persistent (or stored) XSS” vulnerability is an additionally destroying variation of a cross-site scripting defect. It happens when the server saves the information given by the assailant, and after that permanently displays on “normal” pages returned to other users in the course of regular browsing, without appropriate HTML escaping. Stored XSS vulnerabilities can be more noteworthy on the grounds that an aggressor’s vindictive content is rendered naturally — without the need to separately target exploited people or lure them to a third-party website.
Especially on account of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm. The techniques for infusion can change a lot; at times, the aggressor may not have to straightforwardly communicate with the web functionality itself to endeavor such a gap. Any information received by the web application that can be constrained by an aggressor could turn into an injection vector.
If you view the source code of the page, you’ll notice that the application removes all script tags found in the “Message” field to prevent XSS, and it is case insensitive. However, the “Name” field is still exposed to XSS injection since the prevention implemented in the code is only by removing the “<script>” string.
To bypass this security restriction, we can submit the similar scripts that we used in previous examples for reflected XSS.
As you can see in the image below, the medium-security level was compromised.
Once the request is submitted, the script will be executed successfully.