Leaving aside the fact that the ultimate goal of an XSS attack is always to run malicious JS inside a potential victim’s web browser, the ways of its achievement are radically different from each other.

So, let’s take a look at the most popular types of XSS attacks.

What XSS Attacks Can Be?

1. A continuous attack – when malicious code is inside the website database.
2. A reflected attack – when a malicious part of the code is inside the victim’s request.
3. A DOM-based attack – when a potential vulnerability is in the client’s program code but not in a server.

And now, using the example of reflected and DOM-based attacks, let’s look at how you can deal with such hackers’ attacks.

Reflected XSS Attacks

In the process of repelling the XSS attack, any malicious code line is a part of the request to the website. Further, the site includes this line in the response sent to the client.

Structurally, it looks like this:

• The hacker develops a special URL with a malicious line and sends it to a potential victim;
• The victim has already been deceived by the hacker and makes a URL request from the site;
• The site automatically includes a dangerous line in the response body;
• The user’s web browser executes the malicious script from the response body, forwarding the victim’s cookies to the server specified by the hacker.

When Will a Reflected XSS Attack Succeed?

Initially, it may seem that a reflected XSS attack isn’t dangerous. To make the attacker’s plan work, the potential victims need to send the malicious request themselves. Since no one will do this willingly, it seems that the implementation of such an attack is unlikely in reality.

But not everything is so simple, and there are 2 options on how to make the victim to execute a malicious attack:

• If the hacker’s target is a specific user, he sends a malicious URL him, which makes this user to visit a malicious resource;
• If the attacker’s goal is a group of users, the hacker can publish a link to a malicious URL.

Both methods are somewhat similar and are extremely successful when using services that shorten URLs. They can easily mask the malicious line from users who, under other circumstances, would be able to identify it.

Why DOM-Based XSS Attacks Are Dangerous

The progress of modern web programs HTML is generated from JS on a client-side basis, not a server-side basis. If the server code does not contain a vulnerability, the site will be protected from XSS.

This means that XSS vulnerabilities can be not only on the server side but also in the client JS code. It follows that even with secure server code, client code can unsafely trigger client input in a DOM update right after the web page is loaded. If this happens in practice, the user code will allow an XSS attack, and the server code will be left out.

In Conclusion

Of course, XSS attacks are too bad but such actions of web attackers can and should be fought! When developing and testing websites, it is necessary to carefully check the software for vulnerabilities so that the structure of the web resource does not contain “gaps” where malicious JS can seep. After all, if quality consulting companies do not keep abreast, then hackers can get full access to the user’s temporary files, which can include both personal passwords and session IDs, and ongoing transactions.