What is XSS (Cross-Site Scripting)?

XSS or Cross-Site Scripting, is a vector of malware attack where threat actor injects malicious scripts into a certain website. Then, all other users who open this site are getting infected.

XSS - Cross-Site Scripting | Gridinsoft

What is Cross-Site Scripting?

Scripts in se are not malignant; they are sequences of system commands applicable in certain software environments. Advanced users introduce them to automatize durable and repeated procedures the user would otherwise perform manually. However, hackers can use scripts for evil purposes, and one of the ways to do it is to plant their code into web pages.

XSS (Cross-Site Scripting) is a network attack on a computer system. In such an attack, the victim’s machine executes malicious scripts embedded by the hackers into the attack-involved webpage. The script-containing pages can be specially crafted for such attacks or infected with the scripts unbeknownst to their owners. Cross-Site Scripting is abbreviated as XSS, not to confuse it with CSS (Cascading Style Sheets). XSS is a special case of code injection. So criminals do not attack an endpoint directly, jeopardizing it by the attacked system executing malicious instructions itself.

Scripts can take advantage of the permissions user has (being logged in to some system, for example) and can execute their actions technically on behalf of the user, but without the user knowing about it. Hackers use scripts to perform malware downloads, data stealing, spam spreading, DoS-attacks, etc. The variety of XSS effects can be explained by the scope of scripting languages hackers use for such attacks. Most of the malicious scripts are JavaScript commands since all modern browsers support JavaScript, but it can be HTML, Visual Basic Script, SQL, ActiveX, etc.

Why is XSS Possible?

Successful cross-site scripting is always a consequence of an exploited vulnerability on both website and its visitor side. The flaws responsible for possible cross-site scripting on the user's side are the bugs in the browser, usually patched quickly as soon as they are revealed. For example, a browser with a certain vulnerability could execute scripts added to SVG images. Such a defect potentially jeopardizes all users of the imperfect browser. Thus, such overt faults are treated seriously by the developers. There are also specific and hard-to-exploit cases of XSS attack opportunities that may remain unpatched for years.

The rest of the vulnerabilities refer to the websites and are faults in web design. These are some of them:

  • Absence of escape characters where they should be and turn code into plain text, for example, in search requests.
  • The absence of filtering of attributes and their values in allowed tags; for example, a reference link on a forum or message board should hardly be allowed to perform a JavaScript instruction.
  • Encoding format auto-selection can happen due to browsers' ad hoc interpretation of the read code. The title tag placed before the meta tag switches the browser to UTF-7 encoding allowing hackers to perform a malicious HTML code injection somewhere on this website.

These are not all the possible preconditions for cross-site scripting, for hackers are inventive, and the field of thinkable flaws is endless. We must say that trustworthy websites have suffered from cross-site scripting many times throughout the history of the Internet. Facebook, Twitter, Quora, MySpace, Youtube, among others.

Types of Cross-Site Scripting

Cross-site scripting attacks can be classified by different criteria. The two criteria that best clarify the essence of XXS through showing its possible variations are the criteria of persistence and activeness.

Persistent and non-persistent XSS attacks

The persistent XSS is stored on the webpage involved in the attack. If it is a hacker website whose purpose is to be the vehicle for the script, the XSS-ambush can remain there as long as the site exists until the owners wish to remove or alter the malicious script. If the malefactors manage to implant their code into an innocuous website, every visitor who runs onto it will be attacked. Of course, if victims know where and when they were attacked, sooner or later, complaints will reach the website administrators. They will certainly remove the malicious script and the vulnerability allowing it. However, such traps may remain unexposed for a long time and yet deliver their malicious payload, most often – connection to the attacker’s server with subsequent malware downloading.

Persistent scripting
Simplified scheme of persistent XSS

Non-persistent attacks are a curious phenomenon. They are also called reflected XSS attacks. They exploit vulnerabilities of websites that at some point receive data from the client’s end. These can be texts of search queries, content filled in forms, or just website loading options (indicated in a link after an address of a legitimate website). Therefore, non-persistent XSS attacks don’t reside on the websites; they merely reflect a user from those websites to malicious servers or perform harmful actions at once. Why involve a third party – a website, you might ask. The answer is: to take advantage of its trustworthiness. Even if users see a warning about script execution, they would rather consent to it when it happens on a reliable website. The reflected XSS usually finds its victims via malicious links spread through email and social media spam.

Non-persistent XSS
Scheme of non-persistent cross-site scripting

Active/Passive XSS attack

While an active XSS attack happens without any action from the user’s side, it is enough to follow a link or open a website that contains a persistent script to become its victim. The passive attack requires some action to be performed by the user to start. For example, to click some button containing malicious code. Placing the cursor above the active area of the website might also be enough. However, each attack uses a particular vulnerability that the website should have. Therefore the scripts’ “hiding spots” differ, and they are rarely met just like that on an index page.

Anti-XSS Protection

Anti-XSS protection measures can be taken on both the server’s and client’s sides. The former includes various ways to automatize the filtration of scripts on web pages where they are allowed and thoroughly check the website code for vulnerabilities. The latter are the code flaws making scripts technically possible where they are unintended by the web designers.

Users’ security measures

  • 1️⃣ Keeping browsers updated is arguably the most effective way of standing against cross-site scripting. Browsers developers work hard on automatizing the recognition of nocuous scripts, and their progress is reflected in every next update.
  • 2️⃣ Using anti-XSS browser extensions might do the job. These add-ons check form fields, URLs, links, JavaScript, and data-delivering requests for scripts and, if they find any, use filters against them. NoScript for Firefox and NoScript for Chrome are the most well-known examples of such browser plugins. NoScript add-on for Firefox is convenient thanks to a feature of blocking scripts selectively on the same webpage.
  • 3️⃣ The total blocking of any scripts. This measure is 100% effective against XSS but blocks a significant part of the modern Internet. Still, most the cybersecurity analysts recommend this step when you are going to visit untrustworthy pages, especially ones in the Darknet.
  • 4️⃣ Installing efficient security software is the last item on this list, but not the least. First of all, a good antivirus will have a browsing protection function that will not allow your browser to jump to suspicious resources. Should the execution of any script still start (let’s say it is a malicious script embedded in a “good” website,) the antivirus will eliminate any item recognized as malware that the script will attempt to download. GridinSoft Anti-Malware security solution features both mentioned functions and much more.

Frequently Asked Questions

What is the main cause of XSS vulnerabilities?
When a web application takes in untrusted input and does not check it first, XSS vulnerabilities can occur. For example, if a web server puts the input in the page's HTML before sending it to the user's browser, then the code can be controlled by the person who submitted the malicious input.
What information can an attacker steal using XSS?
An XSS vulnerability can allow an untrusted user to take data from other users' session cookies or sensitive data and use it on web pages they create. An XSS vulnerability can also allow an attacker to take over a site or application that an administrative or highly privileged user is using.
What is the impact of cross-site scripting vulnerability?
An attacker might be able to steal the user's account session cookie if they are using a very severe XSS problem. Getting access to cookies means allowing the fraudsters to get your login information, info about location, device, browser used and some personal details. Another common target of XSS attacks is redirecting the user to an exploit page, where it receives malware through browser vulnerabilities. And that will not be a “soft” adware or browser hijacker - exploit pages usually used to deploy spyware, ransomware or an advanced persistent threat.
Does XSS require JavaScript?
XSS is a breach in the security of a web application or site, which makes it easier for a hacker to embed their malicious code. JavaScript was the first and primary language in which scripts were created. However, XSS may have used other resources, such as HTML, Flash, or something else. Most XSS attacks are performed in JavaScript. But to implement malicious JS, the user needs to exploit the vulnerability of the page code on the client or server side. You can also use the Client Security Policy (CSP) to prevent using XSS in current views.
What is blind XSS?
Blind XSS is a variant of persistent vulnerabilities that occur when the web server stores the attacker's data as a malicious scenario in another application. It looks like this: the hacker introduces a malicious payload on the page contacts or reviews, and when the application administrator views the feedback records, the payload will be loaded. An attacker can also be entered in other applications where the administrator reviews the application access or exclusion logs.