Cross-site scripting (XSS) is a type of attack that applies directly to a reliable and secure client-program or website. It aims at embedding its malicious code in the vulnerability of the application or site. The difference between SQL code injection and XSS is the latter targets the user, not the application itself. This attack provides a devastating effect on the online business and its customers. In the end, after this attack, the target machine can get malware through web exploits. Meanwhile, threat actors will be able grab user credentials. Alongside that, data leaks may occur from the site of an endpoint.
Some Types of Cross-Site Scripting
Analysts divide XSS attacks into the two most common types – stored and reflected. There is a third type of XSS that uses the DOM (Document Object Model) as a basis.
Stored XSS
This is a type of attack where the embedded code is constantly present on message forums, servers, databases, comment fields, visitor logs, etc. then the user receives a malicious script from the server when making a request for the stored information. This type can also be called Type-I or Persistent XSS.
The scheme of a persistent XSS attack. The malicious script to redirect the user to the attacker’s server is planted into the legitimate website.
Reflected XSS
Here, hackers execute the attack via links to trusted websites. Such links themselves contain additional scripts that exploit the website vulnerabilities. That is why these are “reflected” attacks. The victim follows a link to a trusted website, but the flaw on that site combined with the code embedded into the link results in redirecting the user to a server with a malicious payload. The malicious links are usually distributed via spam mailings.
The scheme of a reflected XSS attack. The attacker takes advantage of the vulnerabilities of a trusted website and of its reputation.
DOM Based XSS
This is a form of cross-site scripting, where everything happens in the browser. Document Object Model (DOM) is an application programming interface (API) introduced into browsers for browser portability of JavaScript and Java items. The attackers alter the settings of the victim’s DOM in such a way that the browser reacts to certain legitimate and harmless commands with mediated connection to the attackers’ server, allowing the malicious activity.
What can XSS be used for?
When attackers use XSS, they can:
- Perform the actions that the user can perform.
- Distribute and implement trojan programs on websites.
- Capture user account data.
- Masquerading as a victim or impersonating a user.
- Read any data available to the user.
Impact of XSS Vulnerabilities
The impact of a cross-site scripting attack on a user depends mainly on its functions and data, the nature of applications, and the status of the user that the attacker is trying to compromise. Let’s get some examples of these effects.
- The impact is considered minimal for a brochure wire application, where all information is public and users are anonymous.
- The impact will be severe on an application that stores confidential data: emails, bank accounts, and medical records.
- The critical impact will be if the compromised user has elevated privileges in the application. In this case, the attacker can compromise all users with their data through the gained control over the vulnerable application.
Cross-Site Scripting Attack Consequences
The consequences of XSS must be remembered and understood that they are more serious than we think. No matter what type of attack the XSS uses, it is aimed at threatening users. The problems that XSS can cause range from annoyance to completely compromised user accounts and even computers. Also, XSS attacks can cause more serious damage. If attackers want to intercept a user’s session and take possession of the user’s account, they can easily use the disclosure of a cookie.
Other attacks can redirect users to malicious pages or sites, install Trojan programs, change vital content, and more. If the attackers aim to damage the reputation of the company, to influence the price of shares in the company, they will use all the vulnerabilities of XSS.
How to Prevent Cross-Site Scripting Attacks
The level of difficulty of prevention by XSS depends on many factors. Such as the complexity of applications and the ways in which user-controlled data is processed. But in order to figure out how to still warn yourself of XSS, below we will consider the following measures:
- Filter input on arrival. Filter strictly expected or valid input at the moment of receiving user input.
- Encode data on output. To prevent the interpretation of outgoing data, encode it when it appears in HTTP responses.
- Use appropriate response headers. If you want to prevent XSS in HTTP responses which are not content for JavaScript or HTML, be sure to use Content-Type and X-Content-Type-Options headers so that browsers are able to interpret the responses in the way you intended.
- Content Security Policy Use Content Security Policy (CSP) for the last line of protection to help eliminate new vulnerabilities.