Web application security functions like a chain—as strong as its weakest link. When chained together, even small vulnerabilities can turn out catastrophic.
This is a real-world case where I exploited Blind Cross-Site Scripting (Blind XSS) and Cross-Site Request Forgery (CSRF) to gain admin access to a web application. Through a meticulous attack design planned, I was able to create a new admin account—completely oblivious to the actual administrators. Even though the application had CSRF protection and SameSite cookie attributes in place, my approach bypassed these defenses, proving that no single security measure is enough.
Let’s dive into how this happened:
The Discovery
It all started a few weeks prior when I was busy with one of my routine security assessments for a web application. Let’s consider it as:
At first glance, everything seemed secure. But as any experienced security expert will tell you, there’s no such thing as perfect security. You always get to find some or the other weak spot.
While exploring, I stumbled upon a support ticket system that allowed users to send messages directly to the admin panel. I paused for a moment. What if I could inject something malicious into a ticket, and the admin unknowingly ran it?
That’s when I had an idea – Blind Cross-Site Scripting (Blind XSS).
What Is Blind XSS?
To keep things simple:
XSS is a security vulnerability, wherein an attacker can inject malicious code into a web application. The code executes when a user visits the affected application, potentially leading to stolen data or account hijacking.
Blind XSS is more advanced. Unlike regular XSS, where results appear immediately, Blind XSS only runs when a privileged user (like an admin) interacts with the malicious code. The attacker doesn’t see the results immediately — it’s a trap that activates when the admin unknowingly triggers it.
Setting the Trap
I crafted a support ticket and injected a Blind XSS payload into the message. When the admin opened my ticket, my malicious code would execute in their browser. A few hours later, I checked my logs. Success! The admin’s session cookies were captured.
But… when I tried to use the cookies, they had already expired. The admin had logged out, invalidating the session.
Now, this was frustrating. The attack worked, but I didn’t get the result I wanted. Taking a different approach was the only go in this situation.
Before diving into the next phase of the attack, here are some observations.
Observations
During my initial testing, I noticed the following:
Admin Panel URL Exposure – The admin panel URL (https://targetwebsite.com) was visible in the page source.
User Addition Feature – The application (https://example.com) has a subuser adding feature.
Screenshot (a)
This led me to an interesting question: What if the admin panel has a similar feature – admin addition feature?
It was just a hypothesis, but one worth testing.
Let’s Test It
Admin panel URL exposed in the page source:
Given that the application (https://example.com) had a subuser addition feature, it was likely that the admin panel might have a similar endpoint for adding admins.
📌 Possible endpoint: /admin/add
This forms the following URL:
🔗 https://targetwebsite.com/admin/add
Next, let’s test it by using the same parameters in the request body.
The New Plan: Combining Blind XSS with CSRF
What if I could make the admin unknowingly create a new admin account while simply viewing my support ticket?
This is where Cross-Site Request Forgery (CSRF) comes into play.
– Understanding CSRF
CSRF is an attack where an authenticated user (in this case, an admin) is tricked into performing an unintended action on a web application without their knowledge. Such as adding new users or modifying sensitive settings.
– Crafting the Payload
To exploit this vulnerability, I created a malicious script that would automatically send a hidden request to the admin panel—instructing it to create a new admin account. The best part? The admin would unknowingly execute this action just by opening my support ticket.
Payload :
Screenshot(b)
Step-by-Step Breakdown
– Creating an XMLHttpRequest Object
const xhr = new XMLHttpRequest ( );
This line creates an XMLHttpRequest (XHR) object.
By creating the XHR request, JavaScript can send and receive data from a server without refreshing the page.
This is how most web applications work when submitting forms, loading data dynamically, etc.
– Opening a Connection to the Server
xhr.open( ‘POST’ , ‘https ://targetwebsite.com/admin/add, true);
xhr.open(‘POST’, URL, async);
‘POST’ → This means we are sending data to the server (commonly used for form submissions).
‘https://targetwebsite.com/admin/add‘ → This is the URL where the request will be sent. The script assumes that this endpoint allows creating new admin accounts.
true → This makes the request asynchronous, meaning it won’t freeze the webpage while waiting for a response.
– Setting the Content Type
xhr.setRequestHeader( ‘content-Type’ , ‘application/x-www-form-urlencoded’ );
This line indicates that the request contains form data, which is then decoded at the server side. The standard format used at the time of submitting forms through an HTML <form> tag looks like this:
‘application/x-www-form-urlencoded.’
– Sending the Request with Admin Details
xhr.send( ‘ name=hacker&phone=1234567890&username=attacker&password=secret@123’);
The line you see above indicates sending a request with the following data:
name=hacker → The name for the new admin account is “hacker”.
phone=9876543211 → The attacker’s phone number.
username=hacker → The admin username will be “hacker”.
password=Secret@123 → The admin password is “Secret@123“
Here, I used the same parameters from the sub-user creation request in http://example.com while testing the admin addition endpoint. This approach helped me determine whether the admin panel followed a similar structure for adding new users.
This script works quietly in the background. It sends a request to create a new admin account on the server without the admin actually realizing the same. Everything is done automatically when they open my support ticket.
You know what? I couldn’t succeed here. Guess why?
Upon closely analyzing screenshot (a), I noticed the presence of CSRF protection. A CSRF token in the request header. This indicates that the developer has likely implemented CSRF validation in the admin panel as well.
Also Read: Exploiting Firebase Database in a Web Application: A Security Analysis
A Major Roadblock: CSRF Protection
One of the biggest challenges in this attack was CSRF protection. So, how could I retrieve the CSRF token? Where might the developer have stored it?
There’s another common approach—storing the CSRF token within the HTML as a <meta> tag. Many applications follow this method, but it’s not always foolproof. Let’s explore how this works.
– The Challenge: CSRF Protection
The way in which CSRF token is sent along with every request is as simple as stated. To repeat, the requested token should match with the stored one. If it doesn’t, the request gets rejected. This stops attackers from creating requests on behalf of others.
– How I Inserted The CSRF Token Inside The <meta> Tag
- The Server Generates a CSRF Token
Every time a user requests a page, the server-side application simultaneously generates a CSRF token.
The token then gets embedded within the HTML response.
- The Server Injects the Token into the <meta> Tag
It is within the <meta> tag that the token gets included. It is usually within the <head> section of the HTML document that the <meta> tag gets inserted.
This is usually done using server-side templating.
- The Browser Receives and Renders the Page
The browser renders the <meta> tag when it loads the page upon receiving the request. The JavaScript code then reads the token from the <meta> tag for requests.
– How the CSRF Token is Included in Each Request Header
The Browser Retrieves the CSRF Token
JavaScript fetches the CSRF token from the <meta> tag.
JavaScript Adds the Token to Request Headers
With every request made or with every user section, JavaScript includes the CSRF token in the request headers.
The standard header used is X-CSRF-Token.
– The Server Validates the CSRF Token
The server extracts the CSRF token from the request headers upon receiving the request.
It then verifies the token provided by the client with that stored in the session for that particular user.
If both are found to be matching, the token gets validated with the request successfully processed. If not, the request is rejected/canceled.
– Bypassing CSRF Protection
Let’s enhance our previous script by including a function to fetch the CSRF token from the meta tag in the page’s HTML and automatically include it in our malicious requests
Screenshot (c)
This code grabs the CSRF token from the page’s HTML and includes it in the request, fooling the server into thinking it’s a legitimate action.
Step-by-Step Breakdown
Extract the CSRF Token
const csrf token = document . queryselector ( ‘ meta [name= ” csrf-token “]’).getAttribute (‘ content’ );
See the above line. You can see that it searches for a <meta> tag in the HTML by using the attribute
name=”csrf-token”.
The token’s value is stored within the csrf-Token variable upon being retrieved.
Check if the Token Exists
if ( csrf token ) {
This line makes sure that the the CSRF token is present before it proceeds with the request.
The script will not execute the attack if it finds that the token is missing. This is a sure-shot way to avoid any errors.
Include the extracted token
xhr.setRequestHeader ( ‘ X – csrf – Token’, csrf Token);//Adding the CSRF token
Watch as the above line adds a custom HTTP header to the request, i.e., an
X-Csrf-Token header, and assigns it the value of csrfToken (which was extracted from the meta tag).
The Moment of Truth: When the Exploit Worked
A few hours later, I decided to test if my attack had been successful. For this, I needed to navigate again to the admin panel and make an attempt to log in with the credentials I had created a while ago:
📌 Username: attacker
📌 Password: Secret@123
And guess what? I was in.
The admin had unknowingly triggered my attack. Without realizing it, they had created a new admin account on the panel. No session hijacking. No suspicious activity. Everything happened silently in the background.
Lesson Learned: A Small Vulnerability Can Lead to Bigger Consequences
This experiment highlights a crucial lesson—sometimes, a small vulnerability can open doors to much bigger security risks. The Blind XSS-CSRF combination proved highly effective in inducing the attack. By leveraging this technique, I was able to create an admin account without raising any red flags.
One of the key takeaways here is that even if a web application enforces SameSite cookie attributes , this type of CSRF attack, executed using an XHR request, can bypass those protections. Since the request originates from the compromised application itself, the SameSite restriction does not apply, and the attack can proceed as if it were a legitimate user action. This means that relying solely on cookie-based CSRF prevention is not enough.
The above instance was enough to substantiate the fact that your overall security can be weaker than the weakest link. You cannot say if you missed a single tinge of vulnerability. This would be enough to compromise everything completely. Never assume one defense mechanism is sufficient—always layer your security measures!
This was one of the many instances where we conduct penetration tests to judge the security quotient of an application. If you as a business owner are willing to test how secure your web/mobile applications are, you can call us or book an appointment with us. Our cybersecurity experts at Wattlecorp will get in touch with you soon!
Get Your Applications Pen Tested Before Hackers Penetrate them! Because security cannot be compromised!
Blind XSS FAQs
1.How does Blind XSS work?
When an attacker induces a Blind XSS attack, this injects the malicious code into a web application. When saved and triggered later by other users, this executes the malicious code. In other words, while the attacker may have just inserted the code, not knowing where, the authorised users unaware of the same, unintentionally run the concerned code. The latter may have just injected the code without having immediate access to the affected page.Â
2.Is Blind XSS powerful enough to cause data breaches?
Considered powerful than XSS, Blind Cross-Site Scripting is considered highly dangerous when executed by the black-hat hackers. Once executed and triggered, it can cause administrators to run the affected page – one which resembles the original application. When logged in, this leads to losing all critical data and credentials of a business leading to massive data breaches.
3.Can we conduct penetration test using Blind XSS?
Yes, you can. However, there are challenges associated with out-of-band nature of the attack and delayed results because of the injected payload not being visible to the attacker. This is the most challenging aspect of the Blind XSS-induced attack. The attacker (Blind XSS simulator) cannot confirm the success. Unless you combine it with more advanced vulnerability hunting measures, say forgery, you wouldn’t be able to achieve the intended results in terms of threat hunting.
