Immersive Labs: Cross-Site Scripting: Ep.7 — Demonstrate Your Skills
In this lab, I was was hired to perform a web application penetration test of Whisper Messaging, a new application that allows users to send anonymous messages to any registered user.
My task is to explore the Whisper Messaging application to identify at least one reflected, one stored, and one DOM-based XSS vulnerability present in the application.
After registering as a new user.
The Reflected XSS was found right away on User field and for Stored XSS it was done from Message field respectively.
On the next task, we were asked to use stored XSS vulnerability in the user’s inbox to steal the cookies of a user with the username jerry.
What I did was to craft a script to be injected directly to the target user. While doing that netcat was already set forth to listen for incoming connections in the background. As for the script to trigger after the Delivery phase, I infused the “onload” javascript event handler as a trigger. This led us to extract our targets cookie.
This may not go in order but in reality vulnerabilities and exploits doesnt go in order too. What Im saying is that I accidentally answered the last question by using a payload in the search button from the sites dashboard, as that is the only entry point for possible XSS attacks.
I used this payload <img src=”” onerror=alert(“XSS”)> which triggered the DOM-based XSS vulnerabilit to have me finish with the last question.
The second to the last question which is the 10/11th question got me really thinking really hard. As according to the question, I have to identify the stored XSS in the /dashboard page of the site. The dashboard page only consists of a search button (to exploit for the last question), a hyperlinked “here” to redirect to messages page and nothing else.
I scour the internet for answers and still had no clue. After thinking for it for a while, that is when I kinda got a feeling it has to be the supposed “Name” of the registered user, because there literally is nothing there to input. So maybe I dont need to input anything but to just trigger it when I initiate it. I then logged out, created a new username and password. There I went to poke and test a bit on the username field as whatever you input into that field will get reflected on the /dashboard page, making it a candidate for a possible stored XSS attack. I registered this as username <body onerror=alert(1) onload=/> and made up a simple password, then successfully I got registered.
Now the only thing left is to login and once sucessful the malicious script will itself execute as it was already stored on the server’s side. Voila. I finished the line. 🏁