As a web developer, you may know XSS as Cross-site Scripting. It is a way of bypassing the SOP concept. An attacker could easily insert his own HTML code whenever HTML code is generated dynamically, and the user input is not sanitized and is reflected on the page. In this case, the web browser will still display the user’s code since it belongs to the website where it is injected.

The attacker could easily interject JavaScript code which would run under the site’s context. By this way, the attacker can access other pages on the same domain and read data like CSRF-Tokens or the set cookies.

The attacker can use the cookies which typically contain session identifier information, and use it in his own browser and login to the web application as the victim. Another way is by reading private information from the pages, such as read CSRF tokens and makes requests on behalf of the user.

Impacts of the Cross-site Scripting Vulnerability

There are many impacts of an exploited XSS vulnerability. It ranges from Session Hijacking to the disclosure of sensitive data, CSRF attacks and more. The attacker can impersonate the victim and take over the account by exploiting a cross-site scripting vulnerability. It might even lead to code execution on the server if the victim has administrative rights. But it will depend on the application and the privileges of the account. To get more information on how a XSS vulnerability was used in a successful attack can read about the apache.org jira incident .

Preventing XSS Vulnerabilities

The most important thing in preventing cross-site scripting vulnerabilities is to apply a context dependent output encoding. In some cases it might be enough to encode the HTML special characters, such as opening and closing tags. In other cases, URL encoding is necessary if it is correctly applied.

Moreover, your inbuilt XSS filter, even in your most modern web browsers should not be seen as an alternative to sanitization. However, they cannot catch all kinds of cross-site scripting attacks. As a result, this will prevent some pages from loading correctly. Since the idea is to minimize the impact of existing vulnerabilities, a web browser’s XSS filter should only be a “second line of defense”.