Google Gruyere is an intentional web application created with the sole purpose to study and learn on how to find and exploit well-known vulnerabilities. This blog posts will dive into this application for both learning and documenting for myself as well as those interested in finding out how web app vulnerabilties can be exploited.
Intro into XSS
XSS or 'Cross Site Scripting' is a web application vulnerability that basically allows you to inject either Javascript or HTML into a web application that can be injected in the victim's browser. In short, its a code-injection vulnerability, if you're looking at it in a "bird's eye" view. There are different types of XSS vulnerabilities (Reflected, Stored and DOM XSS) which will be elaborated upon in future blog posts.
File Upload XSS
We will utilize Google Gruyere and see how we discover that the vulnerability exists and see how we can exploit it if it does exist (of which it will in this case). Here, we will exploit XSS vulnerability in this application by injecting HTML code within the server and having the server execute the HTML file also known as a 'File Upload XSS'. within this HTML, will be the document.cookie payload which will leak the cookie for the user within this application.
But firstly...Whats a cookie?
HTTP cookies, or internet cookies, are built specifically for web browsers to track, personalize and save information about each user’s session. A “session” in this instance, is the word used to define the amount of time you spend on a site. Cookies are created to identify you when you visit a new website. The web server — which stores the website’s data — sends a short stream of identifying information to your web browser in the form of what we call, cookies. This data that identifies you (also known sometimes as “browser cookies”) is processed and read by “name-value” pairs. These pairs tell the cookies where to be sent and what data to recall.
So, where are the cookies are stored? It’s simple: your web browser will store them locally (on your computer) to remember the “name-value pair” that identifies you. When you return to the website in the future, your web browser returns that cookie data to the website’s server, triggering the recall of your data from your previous sessions.
Let's say that an XSS payload has been injected on a site that is XSS vulnerable and the administrator of a site has no idea about the vulnerability. He has the ability to view, modify and retrieve any sort of critical data about the site and the server itself. The administrator then triggers the payload injected by the we application. with more advanced payloads, the attacker can be able to retrieve the cookie and send requests to the server utilizing the admins cookie, thus resulting in a scenario where the attacker will then "impersonate" the admin, allowing the attacker to then do anything and view anything stored on the server. This is just to give an overview on how severe of a vulnerability this can be.
Finding and confirming XXS Vulnerability
Lets take a look at Google Gruyure Vulnerable Web App:
PS: You can find the vulnerable web application here
Above is how the vulnerable web application looks (You will need to create a user within the site database). DO NOT USE CREDENTIALS YOU USE FOR REAL SITES AND USE THEM FOR THIS ONE. GOOGLE GRUYERE IS SIMPLY FOR EDUCATIONAL PURPOSES ONLY.
For background, we already established that the site is vulnerable to XSS by looking clicking "All snippets", specifically the 'uid' parameter within the URL. Conisider the following:
here we see the URL of Cheddar Mac's "All Snippets". At the end of the url we see that the uid is equal to 'cheddar'. From this point, the most useful thing to do is to identify if the application can render any Javascript code. If it can, we will know for sureb that the site is vulnerable to XSS.
Lets have a look at what we get when we send this back to the server.
Immediately, we see a pop up box that CONFIRMS THAT THE WEBSITE IS VULNERABLE TO XSS. Now lets go on further to develop this payload and retrieve the cookie of this particular user. What we will do to achieve this is to modify the payload and include the document.cookie function in Javascript, that shows the cookie for any of the users that are logged in.
Like this
When we send this back to the server, we get the following results:
We see that the vulnerable XSS application in the uid parameter in the URL shows the cookie of the authenticated user 'Kaizen'. An attacker can use this cookie and modify requests to the server through MITM means and use for malicious purposes.
File Upload XSS Vulnerability
In the web app, we can confirm that the it is XSS Vulnerable through Javascript injection. The next one will be to demonstrate how to craft a payload within an html file, inject the HTML file through application functionality and have the server executed it that has been executed.
Consider the following:
Here we just have an extremely basic HTML file, with the header displaying the message to the user that they're cookie has been stolen as well as the payload to be run on the victim's browser, enclosed within the alert() function with its origin in Javascript. We will use this file and upload in Google Gruyere vulnerable web app. After this the app will show the directory that the file has been saved in. At that moment, once we navigate to where the file will be stored in the server, the simple payload will be executed as well as the HTML file rendered!
Lets see that happening:
We will upload the file here and see the result of that.
Above we see the directory within the server where the file has been uploaded. Let's navigate there.
The final result shows that the vulnerability has been exploited and the cookie has been stolen. This is really a very surface level demonstration of how XSS can be utilized and weaponized against a vulnerable web application.