What is the difference between reflected XSS and stored XSS?

There are some known types of  XSS attacks  happening almost every day to different websites. In this article, we will talk about two types of this attack called reflected and stored XSS attacks. Follow this article to find more about these types.

What is an XSS attack?

The most common and controversial security vulnerabilities in web applications are  cross site scripting or XSS attacks. The nature of this attack is that the attacker somehow injects their malicious script into the web application. The primary victims of this type of attack are users using a web application or website. The hacker can activate a script by the site user, which may prepare hackers to hack what they want. XSS attacks are present in every web application that uses user inputs and output without validation or encryption. The hacker uses cross-site scripting vulnerability, or XSS to send malicious scripts to the victim. The user browser has no way of detecting the insecurity of the script and will run it. Because the victim browser assumes that the scripts were sent from a trusted source, the browser allows that malicious script to access all data.

What is Reflected Attack?

It Vulnerability occurs when an application receives data in an HTTP request and uses - or reflects - the same data without security considerations directly in response to that request; this is why this type of attack is called Reflected XSS.

Suppose a website is searchable and receives a user-searched phrase in the form of a URL parameter: The application uses the searched term precisely in response to this URL: Imagine that the application does not do any other processing on this data; In this case, an attacker could insert a malicious script instead of a parameter specific to the search word in the URL: This URL prompts the app to respond.

If one of the application users requests this  URL designed by the attacker, the attacker script will be run in the victim browser. The critical point here is that when this script runs in the victim user's browser, it runs within that user's session with the application, and it would be perilous for that user because the script has the same access as the users themselves.

What is a Stored Attack?

A stored XSS (also called a persistent XSS attack) occurs when an application receives data from an unreliable source and uses that data without security considerations in its subsequent HTTP replies. Suppose a website allows users to comment on blog posts, and those comments are displayed to other users. Users submit comments with  some special HTTPs  : After this comment is submitted, each user who visits that blog post will receive some data in response to the application: Assuming that the application does not do any other processing on the data, while an attacker can post a malicious comment: The script written by the attacker is then executed on the victim user's browser if they click on it or reply it.

Consequences and effects of these attacks

If an attacker can control the script running in the victim's browser, he or she can usually gain full access to that user's system. For example, some of the actions that an attacker can take are:

- Perform any action in the application that the user uses.

- See any information the user can see.

- Access any information that the user has.

- Interact with other users of that application.

An attacker can force the victim to make requests unknowingly that are under the attacker's control and would cause launching a Reflected XSS attack. For example, a hacker could place a link on a website that he or she controls or place it on another website that she or he is allowed to share content on them and then send the link via email, tweet, or other types of message to the victim. This attack can directly target a specific user or be done in a way that works the same for all users and applications.

Because this type of attack requires an external mechanism to complete the transition phase, the range of effects and consequences are usually less severe than the Stored XSS.

Consequences and effects of these attacks

If an attacker can control a script running in a user's browser, he or she can usually gain full access to that user. If an attacker executes this attack successfully, they will be able to perform all the actions that can be performed in a successful Reflected XSS attack. The main difference between the Reflected XSS and Stored XSS vulnerabilities exploits is that the Stored XSS vulnerabilities allow an attacker to carry out their attacks within the application. In this type of attack, the attacker does not need to find an external way and trick users into sending a request containing a hacker exploit; instead, in this type of attack, the attacker puts their exploit directly into the application itself and waits for users to browse the pages containing the exploit. This feature of Stored XSS exploits is especially useful when an XSS attack can only be performed if users have logged in to the application.

How to find and test Reflected cross site scripting vulnerabilities

Most Reflected XSS vulnerabilities can be found easily and quickly using the Burp Suite Web Vulnerability Scanner. But to find Reflexed XSS vulnerabilities manually, the following steps must be followed:

- Test all input points

Test all ways to enter data into the application via HTTP requests, including other parameters and data inside the URL query, string and the HTTP message's body, and the URL. Of course, do not forget about HTTP headers, although some of the XSS behaviors in the application created only by specific HTTP headers may not be exploitable.

- Record random letters and numbers

Wherever data can be entered, enter a random but specific and recognizable value, and then check whether that value is reflected in the application response. Response means whether the application used it directly in its response or not.

- Determining the context (reflection) of the random value reflection

Specify the value reflection field wherever the application response was randomly reflected; for example, it may be reflected in  text between HTML tags, or within one of the attributes of a tag, and between double quotation marks ("), or even within a JavaScript string scripts.

- Select and test a payload

Depending on the context in which the content is reflected, select an initial XSS feed and test whether it executes JavaScript code and whether it appears unchanged in the application response.

- Test the attack in a browser

All you have to do is enter the URL in the address bar of that browser and check if the injected JavaScript code works. It is usually best to run simple, recognizable JavaScript code so that you can quickly see if an attack is successful. For example, you can use the alert script (document. domain), which causes a pop-up to be displayed on the browser screen.

How to find and test Stored cross site scripting vulnerabilities

Testing for Stored XSS vulnerabilities can be difficult. To do this, you must test all "entry points"; all the domains from which hacker-controlled data must be processed. In addition, you must test all "exit points,"; which means all the locations where the application responses may be displayed.

Some of the data entry points to the application are:

- Parameters or other data inside the URL query string and the body of the HTTP message.

- URL file path.

- HTTP request headers that may not be exploitable for Reflected XSS attacks but must be tested for this attack.

- All routes or out-of-band routes through which an attacker may transmit data to the application should be tested. The available paths depend entirely on the capabilities implemented by the application: for example, a webmail application processes the data received in the emails; an app that displays the Twitter timeline may process data contained in various tweets, and a news collection and display application contains data collected from various other websites.