Making use of Javascript (.JS) files


Javascript (.js) files store client side code and act as the back bone of websites. They help websites perform certain functions such as monitoring when a certain button is clicked, or perhaps when a user moves their mouse over an image. Sometimes developers can obfuscate their javascript code which makes it unreadable to the human eye, however most types of obfuscation can be reversed as we explain below. .js files are often easily overlooked because they contain lots of "weird" looking code which doesn't make too much sense however you just need to know what keywords to search for to extract the useful information. Over time the more you read javascript you will begin to piece it together & understand how it works.

Finding .js files

You can find .js files via a variety of methods. You could very simply just right click on the page you're on and click "view source" (or visit view-source:https://www.website.com/), then begin looking for ".js". If you're a manual hacker then this is the prefered approach as you will notice that certain .js files only contain code for the specific endpoint you're on. For example imagine you are on "https://www.bugbountyhunter.com/challenge" - you may find "challenge.js" which is specificially only for this endpoint. This is helpful when writing notes on how the web application works and how things are peiced together, rather than being faced with massive amounts of data and not knowing what does what.

One thing to note is to not waste time browsing things such as jquery.js. Typically these files do not contain anything that will be of use to you. Go for the custom made .js files referenced.

Another approach is to use a tool called GetJS by 003random which can be found here: https://github.com/003random/getJS. GetJS will take a list of domains and extract any .js files found on each domain. This is useful if you want to sort through lots of .js files for new urls/endpoints (which we explain below) on a mass scale.

If the website you are testing does contain a specific .js file for each feature/endpoint, then you could begin scanning for new js file based on their filename structure. You may see "challenge-final-min.js", so you could begin hunting for common keywords such as "training-final-min.js".

Don't forget that when you discover certain domains that require some type of login to still scan for .js files as they sometimes don't contain any protection and end up revealing more information about the domain and what's behind the login page.

——

Hunting in javascript files

Since .js files contain code which helps websites function, what exactly should you be looking for?

New URLs / Endpoints

.js files sometimes contain new urls and endpoint which lead to more functionality to test (and more chance of bugs!). You can discover URLS by searching for keywords such as their domain name, or "GET", "POST" (which is used for ajax requests). Jobert Abma released a tool called Relative URL Extractor which can be found here - https://github.com/jobertabma/relative-url-extractor. An alternative is GoLinkFinder by 0xsha which can be found here - https://github.com/0xsha/GoLinkFinder.

An example of some javascript code in which URLs may be used (which you want to find).

function reqListener () {
  console.log(this.responseText);
}

var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "http://www.example.org/example.txt");
oReq.send();

New parameters

.js files reference are parameters defined via var = or in ReactJS it could be something such as this.testVariable="test". There are a variety of ways to handle variables in javascript so make sure to also search for common keywords such as "variable" and "redirectUrl" because if it's found, it may lead onto you discovering more. (If their code was partially obfuscated for example). You can also discover parameters via URLs defined, for example /changeView?type=example. The parameter type may not be defined anywhere else but here (and the code may be commented out and not active).

Interesting information

Developer comments (for example // this is a dev comment or /* this is a multi line dev comment */) can sometimes contain information such as when the code was published or any updates that have occured (in the past I have found notes regarding XSS filtering which helped me to understand how they fixed it and thus lead to a bypass). If the code is old there is more chance of you finding an issue!

js files can also sometimes expose more information than intended. An interesting example of this is an admin panel which had referenced in the .js file which upon successful login, redirect to "/dashboard". However, below this, was code used on /dashboard! There was an API endpoint referenced which was when visited gave me access to query any user I wanted. The code was removed and presumably moved to a more discreet .js file (imagine if I found it again somehow?!) & API endpoints changed.

Deobfuscating

de4js is a great online tool which can deobfuscate most types of Javascript & make it readable: https://lelinhtinh.github.io/de4js/

The next time your hunting on bug bounty programs don't forget to take a peek at what .js files are referenced & what they contain. You never know what you may just find!