How Analyzing JavaScript Files Can Uncover Multiple Bugs

3 min readMay 16, 2024

السَّلاَمُ عَلَيْكُمْ وَرَحْمَةُ اللهِ وَبَرَكَاتُه

Peace be upon you, and the mercy of Allah, and His blessings

Hello World !

On April 2nd, I started doing some recon at a specific target BBP Sadly until the time of writing this write-up they didn’t respond to my request for public disclosure So I’m gonna call it redacted

I selected a main domain — a social website with features such as posting, commenting, and messaging users within their platform — and began manual testing.

at some point of that process I went to the main JS file and downloaded it locally so I can read/ go through it for maybe finding something !

it was about 220k line of JS code and I was like “Nah I’d win.”

Of course, I wasn’t going to read all of it (or was I?). I was determined to find a bug in that target to overcome my fear of finding bugs in large companies or public bug bounty programs

So, I mentally divided the JS file into sections. Each day, I would manually test the website, and when I got bored, I would read a portion of the JS file until I finished it.

and I found some code that has some subdomains for that target

var i = t(97871),
        e = t(42868),
        g = t(20737),
        _ = t(38717),
function f(s, r) {
            (this.appService = s),
              (this.responseService = r),
              (this.clientDomains = {
                1111: [
                  "webqa.redacted.com",
                  "localhost:4200",
                  "localhost:4000",
                ],
                "32 chars id smth idk fr!": [
                  "qc-dashboard.rs.zz.redacted.com",
                  "domain-website-something.redacted.com",
                ],
                "something-Redacted": [
                  "place-dashboard.website.domain.redacted.com",
                  "employee-site-testing.redacted.com",
                ],
              });

Among these, only webqa.Redacted.com was operational. It turned out to be their Web Quality Assurance site — a replica of the original site I was testing but with a few new features being tested before going live on the production website. The codebase was almost identical. I downloaded the main JS file to explore further but found little difference.

I noticed something interesting in the staging site’s sitemap. It contained a reference number for a security issue they were likely testing.

In such an environment, developers are more likely to test for critical bugs, which could create a window of opportunity for an attacker. The attacker could monitor the website for a period of time, waiting for a serious bug to be introduced in the staging environment, and then potentially exploit that bug on the production website.

I could monitor it but I thought it might get duplicated

“(if its not you, someone else might report it as it is) “

I reported it as high with CVSS 3.1

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

and in worst cases I thought it might be medium

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

in the end they accepted it as low without giving a reason for that

asked them to clarify it and they did and I actually respected that

always try to communicate with the security team