In the previous part, we introduced the term XSS attack, what it means, how it occurs, and we also mentioned the basic types of XSS attacks and their possible forms. In this part, we’ll walk you through their more modern types and summarize the possibilities of how to defend against them in the web application space.
Modern classification of XSS attacks
Nowadays, attacks are becoming more and more sophisticated and therefore their original categorization is very imprecise. We could summarize the modern classification of XSS attacks into two groups – Server XSS and Client XSS, both of which can be further divided into Reflected Server/Client XSS attacks and Stored Server/Client XSS attacks.
Server attacks are more dangerous because they are performed at the server level, they make changes directly in the application, and the browser then serves only to render the already hacked HTML structure.
In client attacks, the execution of the attacker’s code takes place directly on the browser side – the application appears to be fine on the server and the attack takes place only after the user’s action, which also triggers additional malicious functionality in their browser.
Reflected versions of server or client attacks affect the response from the server, and Stored versions cause the content sent to the user to display differently.
Source: https://dejanstojanovic.net/aspnet/2018/march/handling-cross-site-scripting-xss-in-aspnet-mvc/
From my point of view, even this division is not enough, as pages are usually pre-rendered on the server using SSR (Server Side Rendering) and then classic JS (Vue, React, Angular) is used when rendering or re-rendering part of the page. Therefore it’s possible, and for an effective hack even necessary, to properly combine the attacks.
Tips and tricks to protect yourself from XSS
Treatment of user inputs
It’s necessary to insert functions causing escaping (cancellation) of unauthorized tags and triggered events into each application and website. This useful practice have been repeated to us by our teachers or colleagues in the early beginnings of programming, but it has been forgotten so far.
Always up-to-date technologies
It’s also important to study whether your technologies and frameworks perform sanitation of content or leave all the work to you. For example, my favorite Angular takes care of a large part of the content itself and it also treats the inputs for [src], [href], [style], etc. During manual treatment, don’t forget about tags other than the HTML ones, such as attributes or CSS syntax, which can trigger unwanted code through the style attribute.
Beware of libraries
XSS, but also other attacks such as DDoS, are often a risk due to shared libraries available, for example, in NPM or YARN.
Within the NPM, there’s a simple possibility to verify security by running an “NPM audit” command on your project [link]. I highly recommend checking and upgrading dependencies in regular intervals over each project. In Bart, it’s established that with each release of the main version of a framework, e.g. Angular, we’re moving to the previous main version because of its stability – probably some bug fixes and modifications have already been made to it and therefore this version is safer. At the same time, we also upgrade all dependencies, conflicts and deprecated features of shared libraries.
Blacklist of unauthorized tags
It might help to remove special tags or just starting characters, such as parentheses and quotes – “(, <, >, {,},),”, ‘,“.
Correct use of quotation marks
Essentially, it doesn’t matter if it’s JS, HTML or server languages like PHP, JAVA, and Node (JS/TS) – it’s important to use the correct quotation marks according to the best practice for that language.
Use HTTPOnly cookie flag
If you don’t need your cookies to be readable on the front-end side, hide them – most modern browsers already support this flag. This will effectively block session cookies from being stolen.
Content Security Policy (CSP)
One of the other already mentioned effective methods against XSS attacks is to define which external files (JS, CSS, etc.) can be loaded to your site and from where. If no tool is available, use the standard rules from the “same-origin policy”.
Below you’ll find an example of a code that allows you to download content only from the domain on which the site is located, as well as any associated recommended blocking of external content.
Header X-XSS-Protection
This measure should be used with caution. The header is supported in modern browsers and can create additional client-server risks. In addition to ordinarily adding it to your website (Apache, nginx), you can also force it from HTML.
Use the correct methods to display content
I recommend avoiding the basic “innerHTML” that doesn’t solve problematic symbols. In pure JS, it’s better to use “innerText” – it treats tags and only releases text. In certain situations, “textContent” is also appropriate. It releases text for all sub-elements, including spaces and CSS texts, but without susceptible tags.
Is XSS really such a problem?
Source: https://www.avast.com/c-xss
Yes. Any application that isn’t protected against this type of attack is at great risk. And now that you understand the risks, you probably understand why large companies are spending enormous resources to defend themselves against these attacks. They value your security.
From my point of view, terms such as XSS, Security, Server Maintenance, Testing, Technical Debt and Up-To-Date Dependencies are decisive in distinguishing mature teams and companies from the other ones.
Source Literature:
Useful manual of tags and their possible misuse in untreated situations:
