Let’s be honest. Most APIs are naked without some sort of web app frontend calling it.
These days, those apps are usually written in some sort of framework based on Javascript. With a bit of work, we can do deeper recon against our API targets if we interrogate the Javascript files embedded within the web application.
Let me show you one way to do it using a free Burp Suite extension called JS Miner.
What is JS Miner?
JS Miner is a free Burp Suite Professional extension that finds interesting stuff inside static files like JavaScript and JSON.
You need the Professional edition because it taps directly into the Burp web vulnerability scanner.
If you open up Burp Suite and head over to the BApp Store, you can search for JS Miner and get the full breakdown of what it does. However, there are several features I want to point out specifically:
- It automatically scans for hardcoded secrets and credentials.
- It passively scans for subdomains the web app calls and pulls code and data from.
- It can actively try to construct source code from JavaScript Source Map Files (if found).
- It passively tries to detect API endpoints that use GET/POST/PUT/DELETE/PATCH.
The results are displayed as Issues in the dashboard and Site Map. It can look something like this:
Now let me show you an easy way to add it to your API hacking workflow.
Step #1 – Walk the App
To get the best experience with JS Miner we want to ensure we have downloaded all the static files and packages the web app has. This means we must use as much functionality as possible and cause as much content to download to the browser.
This is an important step.
The reason we do this is because many modern frontend frameworks support the concept of “lazy loading” of code. It can use partial packages, which limits just how much code is downloaded to the browser until it’s needed.
Sometimes this is called “code splitting”. So the more we walk through the app, the more static files and packages will get downloaded.
Step #2 – Let JS Miner scan passively
While you are walking the app, JS Miner will go about passively looking at the incoming static files as they go through the Burp proxy. You may start seeing results pretty quickly in the Site map. Pay close attention to any secrets or credentials it calls out.
You can expect false positives here.
While JS Miner uses Shannon entropy to improve the confidence level of what it detects, the reality is certain keywords will flag. Especially things like “password.” But that’s OK. It’s still valuable data.
As an example, here is an Advisory the extension documented that found routes to interesting password-related endpoints:
Step #3 – Force JS Miner to run an active scan
Once you have walked the app enough and believe you have downloaded all the static content, find the first call into the web app after authentication has succeeded in the Proxy history.
Usually, this should be the root of the app. Probably a dashboard, home screen, or main UI screen after login.
Right-click that request in the Proxy history, and select Extensions > JS Miner > Run JS Auto-Mine (check everything). This will force JS Miner to actively scan everything.
Note that you have to manually trigger this event. Running Burp’s Active Scan won’t do this for you automatically. This is especially important so we can trigger the Javascript Source Mapper in JS Miner.
Step #4 – Check for any JS Source Mapper results
One of the cool features of JS Miner is it will interrogate the web app in search of JavaScript Source Map Files. These are the .map files developers regularly leave on the web server during deployment.
From these map files, JS Miner will try to break apart the packaged web app into individual source files and directories.
The Issue and Advisory may look something like this:
If it does detect the map file(s), it will tell you where the resulting code is saved. You can open that in a terminal to see everything.
You can use that to now easily walk through the code using your favorite code auditing tooling.
NOTE: Don’t give up if the Javascript Source Mapper can’t find the map file(s). You’ll still have downloaded all the code while you walked the app. You can dump all the static files by going to the top of the Site map, right-clicking on it, and selecting Extensions > JS Miner > Scans > Dump Static Files.
You will find an Issue pointing to the output folder where all the code is dumped.
The only downside is the Javascript files may be minified and obfuscated, making it more difficult to parse through.
So fingers crossed that JS Miner detects the .map files. 🤣
Step #5 – Explore the code and extract routes and endpoints
Depending on the tooling you use and your understanding of the Javascript framework being used, you should be able to quickly find interesting routes and API endpoints.
Tools like jsluice might be helpful here. Then again, just running something as simple as tree against the folder will map out a lot that you can quickly look through.
In my case, I can quickly see there is a constants folder that contains APIConstant.js. Looking at that immediately gives us some interesting endpoint routes not seen in the current Site map.
I can further walk through the actions, reducers, middleware, and sagas to get an idea of what events fire requests to the API.
TIP: If you don’t know what I mean when talking about reducers, sagas, and events, it would be a good idea to brush up on common frontend Javascript frameworks like Angular, React, and Redux. While you don’t have to be a front-end developer, understanding how these frameworks function can be immensely valuable as you audit code.
Conclusion
JS Miner can be an indispensable extension for Burp Suite that can help explore and understand the intricate structure of a web application that calls into the APIs you are testing.
We can effectively locate and examine potential API endpoints and source code intricacies by leveraging its capabilities to dissect packaged web apps into individual source files and directories.
This understanding not only bolsters our API security testing methods and proficiency but also enriches our knowledge of apps and infrastructure. It’s an essential part of the API recon process and is something you should highly consider adding to your hacking methodology.
HTH. Hack hard!
One last thing…
Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.
