November 03, 2022
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.
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.
- 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.
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.
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 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. Browser developers work hard on automatizing the recognition of nocuous scripts, and their progress is reflected in every next update.
- 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 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.