Cross-site Scripting

Cross-site scripting is also known as XSS. When malicious JavaScript is executed by a hacker within the user's browser, then cross-site scripting will occur. In this attack, the code will be run within the browser of the victim. Upon initial injection, the attacker does not fully control the site. Instead, the malicious code is attached to the top of a valid website by the bad actor. Whenever the website is loaded, the malware will be executed, and this will load to trick the browser.

JavaScript in XSS

JavaScript is a programming language that runs on a web server inside. The interactivity and functionality are added to the web page using the client-side code. It is used extensively on CMS platforms or all major applications. If the JavaScript code exists inside our browser, it will not impact the website's visitors, unlike server-side language like PHP. JavaScript cannot run on the server because it is client-side. Using the background requests, it can interact with the server. An attacker can use these background requests to add malicious content to a web page without refreshing the web page. These requests can perform the actions asynchronously or gather analytics about the browser of the client.

Working on Cross-site scripting

When the attacker exploits a vulnerability on the software of a website, only then can they inject their code into a web page of the victim's website. After successfully exploiting the vulnerability, attackers can inject their script, which will be executed using the browser of the victim.

When the victim's browser page successfully runs the JavaScript, sensitive information about the target user can be accessed from the session. The session allows an attacker to target the administrator of the site and completely compromise a website.

The cross-site scripting attack will be very useful when most of the publically available pages on the website have vulnerabilities. In this case, the malicious code can be injected by adding malicious content, phishing prompts, and ads on the website to target the website's visitors.

Types of Cross-site scripting attacks

There are various ways to use cross-site scripting based on our goals. The most common type of cross-site scripting attacks is as follows:

Stored Cross-site scripting attack

When a payload is stored by the attacker on the compromised server, in this case, a stored cross-site scripting attack will occur. Due to this, the malicious code will be delivered by the website to the other visitors. In this attack, the initial action is only required by the attacker, and due to this, many visitors have to be compromised. The stored cross-site attack is the most dangerous cross-site scripting. An example of this attack includes the fields of our profile like our email id, and username, which are stored by the server and displayed on our account page.

Reflected Cross-site scripting attack

When the data is sent from the browser to the server, and the payload is stored in that data, in this case, reflected cross-site scripting would occur. An example of this attack includes a contact form or website search data sent to the target and contains a malicious script. Search form is another type of reflected cross-site attack in which a search query is sent by the visitor to the server, and the result can only be seen by visitors. Victims' custom links are sent by attackers that direct visitors toward the vulnerable page.

Self Cross-site scripting attack

When the vulnerability is exploited by the attacker, which requires manual changes and extremely specific context, in this case, self cross-site scripting attack will occur. Specific changes include setting our information to a payload or cookie values types of things.

Blind Cross-site scripting attack

When the result of an attack cannot be seen by an attacker, in this case, blind cross-site scripting will occur. In a blind cross-site scripting attack, the vulnerability lies on that page, which can only be accessed by authorized users. If the attacker wants to successfully launch an attack, this requires more preparation for this. The attack will not get any notification if the payload fails. Hackers can also use polyglots if they want to increase the success rate of these types of attacks. Polyglots can work in different scenarios like a script tag, plain text, and attributes.

DOM-Based Cross-site scripting attack

When the JavaScript on the page is vulnerable to cross-site scripting (XSS), rather than the server itself, in this case, the DOM-based cross-site scripting attack will occur. JavaScript can add interactivity to the page. It can also add arguments in the URL, which is used to modify the page after loading it. The malicious code can be added to a page while modifying the DOM when the user's value is not sanitized. When the URL provides the languages and the website change into these languages rather than the default language, this shows the example of DOM-based cross-site scripting.

Prevention of Cross-site scripting attacks

Website vulnerabilities can be exploited using a variety of methods leveraged by an attacker. If we want to reduce the risk of cross-site scripting, there is no single strategy. Unsafe user input helps the cross-site scripting attacks because it is directly rendered onto the website's web page. This attack would be impossible if the inputs of the user are properly sanitized. We can ensure that the inputs of users cannot be escaped on our website using multiple ways. Using the following protective measures, we can harden our web applications and protect our website.

Whitelist Values

We can restrict the input of a user to a specific whitelist. This practice allows us to only send the safe and known value to the server. If we know about the receiving data, like the content of the drop-down menu, the restricted user input will only work.

Restrict HTML in Inputs

HTML is limited to trusted users. If we want to allow formatting and styling on an input, we can use Markdown instead of HTML to generate the content. If we want to use HTML, we should sanitize it with a robust sanitizer like DOMPurify, which is used to remove all the unsafe code.

Sanitize value

If we are using content on a page generated by a user, we should ensure that it would not result in HTML content by using entities in place of unsafe characters. The appearance of regular characters and entities is the same, but the entity cannot generate HTML.

Use HTTPOnly Flags on Cookies

Session cookies are used to allow a website to recognize a user between requests. An attacker frequently exfiltrates the user's cookies and steals the admin session. Once the attacker steals the cookies of a user, they can log in to the account of the admin without authorized access or credentials. HttpOnly cookies are used to prevent the JavaScript from reading the cookie's content and increase the difficulty of an attacker stealing the session. Using this method, we can only prevent our cookies from the attacker. An attacker can still act as an admin user and send a request using the active browser session. If the attacker uses cookies as the main identification mechanism, in this case, this method will be only useful.

Use WAF

We can virtually patch attacks against our website using the firewall. This method is used to intercept the requests like SQLi, RCE, and XSS before our website gets malicious requests. The large scale attacks like DDOS can also be protected by it.