Cross-site scripting XSS attack Types of Attack & Preventions

What is Cross-site Scripting (XSS)

Cross-site scripting is often referred to or abbreviated as XSS because it occurs on the client-side. Here the attacker aims to inject some malicious scripts into the user’s web browser, by sending a link to the user and provoking the user to click it. If any action is performed by the user on those links, then the actual attack occurs, resulting in stealing the user’s active session cookies, sensitive data, session hijacking, and much more. But it can only occur when the web application or app is vulnerable to XSS attacks that means if the website or app lacks/misses some proper data sanitation then the codes present on those links can harm the client-side web browser.

The attackers do not have specific targets. In many cases, they do go for a direct way that is via email messages. XSS attacks can be done by using different programming environments including VBScript, Flash, ActiveX, JavaScript, and even CSS. However, JavaScript is mainly used for these types of attacks because JavaScript is fundamental to many websites.

How does Cross-site Scripting Works?

Let us imagine, a user is sitting on his computer and visiting a web page that is filled with interesting headlines, funny videos, ads for sporting goods, online stores, and a payment site. With a simple click on any advertising, the banner triggers another page. Now here comes the two stages of a typical XSS attack:

• The attacker first finds a way to inject the malicious JavaScript code into the user’s web page that the user is visiting.
• Now since the user is visiting the web page containing the malicious JavaScript code, the attacker then uses social engineering and/or phishing to send malicious URLs to the user which is connected to the attacker’s account.

These attacks can also trigger automatically, while page loads or when a user visits some specific elements of the page. There are also some consequences of cross-site scripting attacks, that includes:

• Capturing the keystrokes of a user.
• Redirecting the user to a malicious website.
• Running a web browser that is crashing the browser.
• Obtaining the cookie information of a user.

There are also some cases where the attack leads to complete compromise of the user’s account.

Types of XSS/Cross-Site Scripting Attacks

Since we have discussed working of cross-site scripting, now let us know about the types of cross scripting attacks:

There are 4 types of cross-scripting/XSS attacks:

• Stored XSS attacks – It is also known as Persistent Cross-site Scripting. In these attacks, the injected JavaScript codes are permanently stored on the user’s server like in the databases, in a message forum, visitor log, etc. The most frequent targets are those websites that allow the users to share content, including blogs, social networks, video sharing platforms, and message boards. The number of times the infected page is viewed, the malicious script code is transmitted to the user’s browser. For example, a marketing approach displaying social media posts, or a network monitoring approach displaying packet data from network traffic.

• Reflected XSS attacks – It is also known as Non-Persistent Cross-site Scripting. In this type of attack, the injected JavaScript code is reflected off the web server in the form of error messages, search results, or any other responses that include some part of the request. The delivery of this attack can be via another route like e-mail messages or some other websites. An example of Reflected cross-site scripting can be a search form, where users upload their search query to the server, where only they can see the results. Then the attackers send the user’s custom links that redirect towards a vulnerable page. Hence, from this page, they often employ a variety of methods to trigger their proof of concept.

• Blind XSS attacks – It is the form of persistent XSS which occurs when attackers are not sure about the result of the attack because the vulnerability lies on the page which can only be accessed by an authorized user. Since the attackers do not get notified, they often use polyglots which are designed to work in different scenarios. Let’s take an example of feedback forms, where the attacker submits a malicious payload using the form, and when the backend admin of the application opens the attacker’s submitted form via backend application, the attacker’s payload then gets executed.

• DOM-Based XSS attacks – The full form of DOM is Document Object Model. Here the attackers can read and manipulate the DOM data and can craft a malicious URL. The attackers provoke the users to click on the URL so that they can steal user’s active session information, keystrokes, and so on. The DOM-Based XSS attack occurs entirely on the client’s browser.

How to avoid XSS vulnerabilities?

There are few strategies that can help to avoid XSS vulnerabilities and these include:

• Do not trust user input.
• Execute output encoding.
• Perform user input validation.
• Do follow the Defence in Depth principle.
• While developing a web application, ensure to align it with OWASP’s XSS Prevention Cheat Sheet.
• Also, perform penetration testing to confirm the result.

The organization can also be protected by following secure development guidelines. Output encoding is the key to avoid XSS vulnerabilities.

Cross-site scripting (XSS) examples

The main goal of an XSS attack is to access the user’s information. Let’s look at some examples of these attacks:

• Session Hijacking – It is considered the most dangerous and widespread method of web session hijacking. So, it is mainly done to exploit the web session control mechanism, which is managed for a session token. The attacker can cause harm to the session token by using malicious JavaScript code running on the client side. If the attacker sends the malicious link to the user and the user clicks on the link, then the code will run and the attacker can obtain full access to the session key. Hence, it is very important to set the server in the HttpOnly attribute in session cookies.

• Phishing attacks – The attack without an XSS component happens when the attackers try to make the fake link as real as possible to the user or victim. These links are generally the textual form of a trusted URL with a hyperlink to another website or a brand’s website. The fake links are inserted with the number to make the link appear real. In the attack, with the XSS component, query strings are injected into the malicious URLs and are sent to the victims which makes the fake URLs harder to spot. Phishing attacks done using query strings are very effective because the URLs of actual websites are used rather than fake links.

What are the consequences of XSS attacks?

The consequences that may occur due to these attacks are:

• The attackers can read any data and perform arbitrary actions which may include postings on social media or bank transactions.
• Stop user’s input.
• Ruin web pages.
• They can inject malicious codes into the web pages.

Uses of Cross-Site Scripting

The attacker who exploits the cross-site scripting vulnerability is able to:

• Impersonate as the victim user.
• Carry out any action that the user is able to perform.
• Read the data that the user is accessing.
• Capture the user’s credentials.
• Inject Trojan functionality into the website.

Cross-site scripting/XSS attack prevention

• Maintain Awareness – While developing a web application the development team that is developers, QA staff, DevOps, and SysAdmins should be aware of the risks associated with the XSS vulnerabilities.

• Distrust User Input – The user input used as a part of HTML output may have a risk of XSS. So, the user should treat every input as untrusted.

• Sanitize HTML – As the user input should contain HTML, it can’t be escaped/encoded as it might break some valid tags. So, in such cases, the user can use a trusted library to parse HTML.

• Set HttpOnly flag – The HttpOnly flag is set for cookies because it is not accessible via client-side JavaScript.