What is an XSS vulnerability and how tester cannot miss it?

Cross-site scripting vulnerabilities are one of the few vulnerabilities on the Top 10 Web Application Security Threats list published by all OWASP or Open Web Application Security projects.

Cross-Site Scripting (XSS) is a client-side code injection attack. An attacker attempts to run malicious scripts in the victim's web browser by embedding malicious code in a legitimate web page or web application. When a user visits a web page or an application, it is the moment of the real attack with malicious code. The web page or web application becomes a tool to send malicious scripts to the user's browser. Vulnerable tools commonly used in cross-site scripting attacks include pages or channels that allow you to comment on posts.

If a web page or web application uses unfiltered user input in the generated output, it is vulnerable to XSS attacks. The victim's browser should analyze this user input. XSS attacks can occur in Active X, Flash, VBScript, and even CSS. However, since most basic JavaScript actions use navigation functions, these vulnerabilities are most apparent in JavaScript.
How Cross-Site Scripting Works

A typical XSS attack is divided into two phases:
1. To run malicious JavaScript in the user's browser, the attacker must first devise a way to inject the malicious code (payload) into the web page visited by the user.

2. The victim must visit a web page containing malicious code. If an attack is targeting a specific victim, the attacker can use social engineering and / or phishing to insert malicious URLs to the victim.

For the first step to happen, the affected website must include user input directly on its page. The attacker could then add a malicious string that would be used on the web page and treated as source code by the victim's browser. There are other variants of XSS attacks wherein an attacker uses social engineering to direct the user to a URL and the payload is part of the link that the user clicks.

Different types of cross-site scripting vulnerabilities

There are three different types of cross-site scripting vulnerabilities
Stored cross-site scripting vulnerabilities

When the payload is stored, for example, in a database, a stored cross-site scripting vulnerability is created which is then executed when a user opens a page in a web application. Stored Cross-site scripting is very dangerous for many reasons:

 - The payload is not visible to the browser's XSS filter.
 - If the user visits the affected page, the user could accidentally trigger the payload and need to take advantage of the mirrored XSS with a well thought out URL or specific form input
DOM-based cross-site scripting vulnerability

DOM-based XSS vulnerabilities occur in DOM (Document Object Model), not HTML
Reflected Cross Site Scripting Vulnerabilities

When a user mirrors input from a URL or POST data on a page without storing it, an XSS vulnerability exists that could allow an attacker to inject malicious content. This means that the attacker must send the victim a carefully crafted malicious URL or email form to insert the payload, and the victim must click the link. This payload is also usually captured by the XSS filter built into the user's browser (such as Chrome, Internet Explorer, or Edge).
Impact of cross-site scripting vulnerabilities

The impact of exploited XSS vulnerabilities in web applications varies greatly. It goes from hijacking a user's session. When used with social engineering attacks, it can also lead to confidential data disclosure, CSRF attacks, and other security vulnerabilities. By exploiting cross-site scripting vulnerabilities, an attacker can impersonate the victim and take over the account. If the victim has administrator rights, it may even cause code to run on the server, depending on the account and application privileges. Read more about the apache.org jira incident to learn how to exploit XSS vulnerabilities in successful attacks that also resulted in code execution.
Prevent XSS vulnerabilities

To avoid XSS security vulnerabilities, it is very important to apply context-sensitive output encoding. In some cases, encoding special HTML characters (such as start and end tags) may be sufficient. It is important for QAwerk to use the correct URL encoding. If the link does not start with a whitelist protocol (such as http: // or https: //), the link should generally be denied, thus avoiding the use of URI schemes in QA outsource (such as javascript: //).

Although most modern web browsers have built-in XSS filters, they should not be considered an alternative to curation. They cannot detect multiple cross-site scripting attacks and are not strict, so they do not cause false positives, which will prevent some pages from loading correctly. A web browser XSS filter should only be a "second line of defense" to minimize the impact of existing vulnerabilities.