Reflected XSS – Explained with a real world example

OVERVIEW OF THE VULNERABILITY:

Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Suppose a website has a search function which receives the user-supplied search term in a URL parameter:

https://davindertutorials.com/search?term=hello

The application echoes the supplied search term in the response to this URL:

<p>You searched for: hello</p>

Assuming the application doesn’t perform any other processing of the data, an attacker can construct an attack like this:

https://davindertutorials.com/status?message=<script>/*+Bad+stuff+here…+*/</script>

This URL results in the following response:

<p>You searched for: <script>/* Bad stuff here… */</script></p>

If another user of the application requests the attacker’s URL, then the script supplied by the attacker will execute in the victim user’s browser, in the context of their session with the application.

AFFECT OF THE VULNERABILITY
 
If an attacker can control a script that is executed in the victim’s browser, then they can typically fully compromise that user. Among other things, the attacker can:

  • Perform any action within the application that the user can perform.
  • View any information that the user is able to view.
  • Modify any information that the user is able to modify.
  • Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

There are various means by which an attacker might induce a victim user to make a request that they control, to deliver a reflected XSS attack. These include placing links on a website controlled by the attacker, or on another website that allows content to be generated, or by sending a link in an email, tweet or other message.

Because of the external delivery mechanism for the attack means that the impact of reflected XSS is generally less severe than stored XSS, where a self-contained attack can be delivered within the vulnerable application itself.

REAL WORLD EXAMPLE OF THIS VULNNERABILITY:

PUBG’s main website https://www.pubg.com has an endpoint that is vulnerable to an injection vulnerability – namely a reflected injection of JavaScript, also known as Reflected Cross Site Scripting (XSS).

Steps To Reproduce:

How this can be done by attacker

Prepare a JavaScript payload that it wants the victim to execute. In this case, for Proof of Concept purposes, our JavaScript code will prompt an alert showing the users’ cookies.

alert(document.cookie);

Inject this Javascript code properly into the vulnerable parameter, creating thus a crafted future GET request that will inject the payload.

GET /?p=iqz78'%3e%3cimg%20src%3da%20onerror%3dalert(document.cookie)%3d1%3echplq HTTP/1.1
Host: www.pubg.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: https://www.pubg.com/es/feed/
Cookie: _icl_current_language=en; _icl_visitor_lang_js=en-us; wpml_browser_redirect_test=0; __cfduid=de74423d435717d651b1c9e2c63f4acc21575460678

As this injection happens in a GET parameter, the attacker simply needs to send the crafted Link that produces this GET request to the victim and have the victim click it.

Write a comment