Displaying otherwise non-existent ads, theft of login data from forms, or even mining cryptocurrencies while reading online news. This is what an XSS (cross site scripting) attack might look like. In order to be able to identify it, in the following blog you’ll learn exactly what it looks like and what are the types. Later, in the sequel, we’ll introduce you to the possibilities of defending yourself.
What is XSS?
An XSS attack doesn’t work like in movies where a hacker gets into your computer or server and steals your data, images or sensitive documents. XSS attacks are primarily targeted at users of web applications and portals.
Minor damages that a successful XSS attack can cause include, for example, displaying ads on sites where ads are not switched on at all. Somewhat worse are the consequences of attacks where the login data from forms is sent directly to the hands of the attacker (E-bay, for example, faced such an attack). Also common is the misuse of sites and cryptocurrency mining applications, which the QNAP network drive manufacturer had to contend with too at the end of last year.
The reason for frequent attacks is, for example, the popularity of Single Page Applications (SPA) – applications with a code made up largely of dynamic JS, which is easy to manipulate for the attackers.
Source: https://unsplash.com/photos/ZjX-z2Q5zrk
Similarly, the current war situation in Ukraine and the ongoing fight in the digital space help these attacks. DDoS (Distributed Denial of Service) attacks are particularly popular. Their aim is to maximally overwhelm the server of the desired enemy page or application and thus to bring it down and prevent users from accessing it. My colleague Dominik wrote about this topic recently, you can read his article HERE.
DDoS attacks are also often used by so-called ethical hackers (they don’t harm, but test and detect bugs, vulnerabilities, and thus help websites to protect themselves), such as the Anonymous defensive group that obstructs the codes of websites and applications of the Russian government to prevent the spread of disinformation.
Inconspicuous thieves
With a sophisticated XSS attack, you initially don’t notice any problems. A plugin, application or website can work properly and reliably. However, at some point or in certain situations, such as logging into a bank account or social networks, a small part of the code replacing the original code is activated and it changes or extends its function. For example, the PIN input field is extended with a function for automatic transfer of data to an external server, which, however, has no connection with the original secure server of the application. On the contrary, it’s directly connected to the hacker.
Source: https://portswigger.net/web-security/cross-site-scripting
Therefore, we recommend only installing verified and known applications on your computers or mobile phones and only visiting official websites. Various plugins and browser extensions need to be approached with the same care. Personally, I’m also vigilant when it comes to mobile apps that forcefully try to open content in their browser integration. Such behaviour is, at the very least, suspicious.
How to become a hacker?
The main task of XSS attacks is to insert and make a foreign code function. It isn’t difficult, just run the page in your favorite browser, open a developer console (DevTools) for it, find out some functional JavaScript (JS) and add the required changes.
Now you might be thinking that if you inserted your JS into DevTool, hooray, you’ve become a hacker. It doesn’t work that way, unfortunately. You won’t hack anyone by ruining the interpretation of the page in your browser. You still need to get the bug to the web browser on your victim’s computer. This is possible by running a script, or even by submitting the execution of a whole block of code that the browser doesn’t know is not the original code with the original intention.
Source: https://www.quora.com/What-is-cross-site-scripting
For example: a user enters content in the text area on a web page. However, the website developer has treated the content incorrectly or not at all and will use it by setting the “innerHTML” attribute. The content thus becomes part of the page code and is displayed to all its users. If the content is a script, the page doesn’t perceive it as text, but as a command that it executes.
Such an error was quite common at the beginning of the web, which is why in blog or forum comments, malicious codes were appearing often, invoking external functions that could, for example, track the position of the cursor on the page or even capture all your keystrokes and thus detect any passwords.
Attacks using activating functions from external sources can be prevented, for example, by setting the correct “same-origin policy”. It defines the domains and addresses from which external content can be downloaded (images, js, css, etc.) However, this procedure isn’t always effective, especially when it comes to simpler and smaller script injections, without the need for externally loaded codes – they simply become part of the web, they are carried out and then cause problems. The basis is therefore the correct identification of possible risks.
Basic (somewhat old-school) division of XSS attacks
Reflected XSS (AKA Non-Persistent or Type I)
Source: https://www.securitydrops.com/360-xss/
This is a fairly simple way to execute an XSS attack. The malicious code is sent in the form of a response to a HTTP request, most often during searches, error messages or other responses that return usable data for the web or application.
Stored XSS (AKA Persistent or Type II)
Source: https://avinetworks.com/glossary/cross-site-scripting/
An attack that is often sent in the form of an automatic e-mail informing you about a response to your comment. In this case, the data is stored in an unsecured storage and distributed to one or more recipients where the malicious code is executed.
DOM Based XSS (AKA Type-0)
Source: https://brutelogic.com.br/blog/dom-based-xss-the-3-sinks/
This type of attack represents the example already described above. The received content in a certain way modifies the DOM structure of our site. The structure (DOM = Document Object Model) is written in HTML language (nowadays, HTML5 is the most modern) and represents a cluster of tags – symbols, carrying information about how the page is made up and how it should work. Therefore, if malicious code becomes part of it, every page load will trigger this code and damage the user. Uploading harmful content directly into the DOM through “innerHTML” without proper treatment and sanitization can be catastrophic.
However, this basic division is now obsolete, because the forms of attacks can be combined together. At the same time, it’s becoming increasingly difficult to defend against them. In the next blog, we’ll therefore look at the modern division of the XSS attacks and practical steps to combat them.
