Cross-Site Scripting(XSS) Explained

What is Cross Site Scripting?

A cross-site scripting attack(XSS) is a Code injection attack executed on the Client-side of the Web application. The Client-side is usually the software used to interact with the web app. In most cases, it is the web browser. So in an XSS attack, the attacker injects a malicious code into the web browser. The attacker does this in order to make the web application do something which it is not supposed to do. The attacker injects the malicious script through the web browser. This malicious script gets executed on the web application after injection. The script gets executed either when the victim visits the web page or the web server.

There are different kinds of XSS depending on the type of malicious code. Attackers use this attack mainly to steal sensitive information like website cookies, session tokens, and other different types of information.

The attacker can also use to modify the web contents of the web application. As this attack is a code injection attack, the attacker can inject malicious code to modify the content of the web server or web page.

How Cross Site Scripting (XSS) works?

Technically, Cross-site scripting is a web application hacking technique that requires a web application, a web server, and a victim. When we use a web application, we interact with it, we send the data to the server, sometimes we send the data through HTML forms. And even if we don’t, some transaction of data is always happening in the background between you and the web server. So, you basically send a request to the web server, the response is generated which is then sent back to you via the web page.

In Cross-site scripting, the attacker can inject malicious code onto a website. This code is then sent to the web server or the victim depending on the attack type. The malicious code gets executed. This happens when the victim visits the web page or when the victim tries to access the data from the server. While this happens, the attacker injects a malicious script to steal sensitive information like credentials.

Types of Cross Site Scripting Attacks

Reflected XSS (Non-persistent)

In a reflected cross-site scripting attack, the malicious code doesn’t get stored in the web server. The script gets executed on the client-side. It gets executed mainly on the web browser. The attacker does not send the script to the web server. Even depending on the API calls or requests even if the code is sent to the web server, it gets executed on the client-side. So even after sending the script to the server, it does not get stored. The malicious script gets reflected on the victim’s side. It’s not really stored on the server which is the reason behind we call it Reflected XSS.

Stored XSS (Persistent)

The script is stored and executed on the web server. The malicious code gets executed every time the web page is requested. Unlike reflected XSS the data gets stored on the web server. For example, if you comment on some Instagram post, it gets stored on the database of Instagram’s web server. Similarly, the malicious code gets stored on the web server. So, every time if someone tries to access the web page or web data, the malicious code gets executed. The web server fetches the request from the user and displays it on the web browser. When the attacker attacks the website using a Stored XSS attack, the malicious code gets stored on the database of the web server. So every time any user tries to fetch that data, the malicious code gets executed.

DOM XSS

DOM stands for Document Access Model. Document Access model is a model on basis of which the website gets built. Document model Cross-site scripting is a client-side attack. The attacker doesn’t send the malicious script to the web server. This attack unlike the Stored XSS, doesn’t involve storing the data on the web server. A legitimate server script gets executed followed by a malicious script. When the victim sends a request to the server, the legitimate server script gets executed first. After that, the attacker injects the code in such a way that the script gets executed after the legitimate server script.

Leave a Comment

Your email address will not be published. Required fields are marked *