Permanent means that the attack will be stored in the back-end system. In normal XSS attacks an attack 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' session the attacker might attack an administrator to gain full control over the application.
Permanent XSS is a dangerous issue that has many exploitation vectors, some of which includes:
User 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.
Prior to sanitizing user input, ensure you have a pre-defined list of both expected and acceptable characters with which you populate a white-list. This list needs only be defined once and should be used to sanitize and validate all subsequent input.
Cookie was not marked as HTTPOnly. HTTPOnly cookies can not be read by client-side scripts therefore marking a cookie as HTTPOnly can provide an additional layer of protection against Cross-site Scripting attacks..
During a Cross-site Scripting attack an attacker might easily access cookies and hijack the victim's session.
Actions to Take
See the remedy for solution
Mark the cookie as HTTPOnly. This will be an extra layer of defence against XSS. However this is not a silver bullet and will not protect the system against Cross-site Scripting attacks. An attacker can use a tool such as XSS Tunnel to bypass HTTPOnly protection.
Netsparker identified that the target web server is disclosing Apache Coyote version in the HTTP response. This information can help an attacker to gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache.
An attacker can look for specific security vulnerabilities for the version identified in the SERVER header. The attacker can also use this information in conjunction with the other vulnerabilities in the application or the web server.
Configure your web server to prevent information leakage from the SERVER header of its HTTP response.