Test name: Stored-Site Scripting (XSS)
The web application stores malicious data in a long-term storage, typically a server-side database. This malicious code is then included in the HTTP response from the server to the client, either to the same client or a different one. The client receives the response and trusts the content, unknowingly interpreting the malicious code as trustworthy. This dangerous data can later be incorporated into dynamic content. Consequently, an attacker gains the ability to perform any actions that a victim user can on the client side, including accessing cookies, session tokens, and other sensitive information.
This vulnerability allows an attacker to:
- Execute unauthorized code or commands
- Bypass protection mechanism
- Read the application data
- Deface the application
The issue can be found in the source code on the server side.
Since the information is returned from the server-side, the most effective solution is to prevent dangerous data from being created on the server.
The general recommendations are the following:
- Treat all user input as untrusted. All user inputs should be strictly filtered and precisely validated (whitelist approach).
<div>tag). But it doesn't work if you put untrusted data inside the
<script>tag anywhere, or an event handler attribute like
onmouseover, or inside CSS, or in a URL. You must use the encode syntax, which is suitable for the part of the HTML document you are putting untrusted data into. To make sure that these rules are properly implemented, we recommend using a security-focused encoding library, for example:
Updated about 1 month ago