Download Netsparker
Pricing
Blog
Contact
Netsparker

Permanent Cross-site Scripting Identified on Target Web Application

Netsparker identified permanent cross-site scripting, and confirmed this vulnerability by analyzing the execution of injected JavaScript.

Permanent XSS allows an attacker to execute dynamic scripts (JavaScript, VBScript) in the context of the application. This allows several different attack opportunities, mostly hijacking the current session of the user or changing the look of the page by changing the HTML on the fly, to steal the user's credentials. This happens because the input entered by the user has been interpreted by HTML/JavaScript/VBScript within the browser.

"Permanent" means that the attack will be stored in the backend system. In normal XSS attacks, an attacker needs to e-mail the victim, but in a permanent XSS an attacker can just execute the attack and wait for users to see the affected page. As soon as someone visits the page, the attacker's stored payload will get executed.

XSS targets the users of the application instead of the server. Although this is a limitation, since it only allows attackers to hijack other users' sessions, the attacker might attack an administrator to gain full control over the application.

Impact

Permanent XSS is a dangerous issue that has many exploitation vectors, some of which include:
  • User's session-sensitive information, such as cookies, can be stolen.
  • XSS can enable client-side worms, which could modify, delete or steal other users' data within the application.
  • The website can be redirected to a new location, defaced or used as a phishing site.

Remedy

The issue occurs because the browser interprets the input as active HTML, JavaScript or VBScript. To avoid this, all input and output from the application should be filtered. Output should be filtered according to the output format and location. Typically the output location is HTML. Where the output is HTML, ensure all active content is removed prior to its presentation to the server.

Prior to sanitizing user input, ensure you have a pre-defined list of both expected and acceptable characters with which you populate a whitelist. This list needs only be defined once and should be used to sanitize and validate all subsequent input.

There are a number of pre-defined, well structured whitelist libraries available for many different environments; good examples of these include the OWASP Reform and Microsoft Anti cross-site scripting libraries.

Remedy References

External References


Go back to the Complete list of Vulnerability Checks.