What is XSS (Cross-Site Scripting)?

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.

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

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.