JavaScript is one of the most popular programming languages, and modern web applications heavily rely on this framework. Starting from API calls, many critical functionalities are built on the client side nowadays. Through this blog, I will demonstrate how to automate your task to find unique vulnerabilities in JavaScript files.
Insecurities in Javascript
In the context of cybersecurity, JavaScript frameworks perform client-side validation of user input before submitting it to the server. This helps to catch errors and prevent invalid data from being sent, improving the overall security and reliability of the web application. However, there are risks associated with data leakage or exposure, which can lead to Personally Identifiable Information (PII) leakage. When attackers gain access to such information, they can exploit it to interact with APIs and make unauthorized changes.
Methodology
A web application crawling tool for crawling endpoints you can use Burp Crawler, Gau, and Waybackurl. I will be using Hakrawler. Hakrawler is a Go web crawler designed for easy, quick discovery of endpoints and assets within a web application.
Crawling of the web resources including javascript files….
The first approach is to find and sort js files related to the selected target host “example.com”.
We can use Burp Suite for crawling through the website by simply navigating through traffic and filtering out the js files after the crawling is done.
Using Wayback urls is also an option when coming to crawling for endpoints, especially here .js endpoints Using WaybackMachine might result in false positives i.e. JavaScript files that don’t exist on the server anymore.
“waybackurls example.com | grep “\.js” | uniq | sort”
And save the output in a file “js.txt”
For automated scanning to detect hidden secrets, API keys, and other sensitive information, you can leverage various tools and techniques, including grep, regex-based tools, and specialized scanning tools like Secret Finder and Mantra.
Here’s an example of how you can use grep and regex-based tools to search for sensitive information:
- Using grep:
grep -rE '(access_token|api_key|secret_key)' /path/to/scan
This command recursively searches for files in the specified directory (/path/to/scan) for patterns matching ‘access_token’, ‘api_key’, or ‘secret_key’.
- Using regex-based tools: You can create custom regular expressions to match specific patterns of sensitive information. For example:
access_token\\$production\\$[0-9a-z]{16}\\$[0-9a-f]{32}
This regex pattern matches strings indicating an access token in a production environment, followed by a 16-character alphanumeric sequence and a 32-character hexadecimal value.
- Using specialized scanning tools: Tools like Secret Finder and Mantra are specifically designed for searching the source code of web pages and script files for sensitive information. Mantra, for instance, uses pre-defined regular expressions like the one mentioned above to identify API keys and other sensitive data.
To use Mantra, you would typically provide it with the files or directories to scan, and it would utilize its built-in regex patterns to identify potential leaks.
Here’s an example of how you might use Secret Finder or Mantra:
secretfinder /path/to/scan
mantra scan /path/to/scan
Replace /path/to/scan with the directory or files you want to scan for sensitive information.
By combining these tools and techniques, you can automate the process of detecting and mitigating potential security risks related to leaked data, API keys, and other sensitive information in your codebase or web applications.
Validate the API Keys
Feed this sorted data to mantra using the following command
“cat js.txt | mantra”
The output will have a resource related to each endpoint, validated if the keys are truly positive or not.
There are API keys which are meant to be exposed in a client-side script, for example, Firebase project API keys which are meant to be exposed, and other API keys which are not meant to be exposed, which have a much broader scope. For example, if you’re pen testing a web application and you find a client-side secret key, which can be used for testing for misconfigured OAuth functionality of a web application. Another example would be exposed Google API keys which have Geocoding, which shouldn’t be exposed to the public unnecessarily.
Conclusion
There are some good ways to prevent this unintended exposure. One major step would be to set API key restrictions, even if it’s meant to be exposed, and configure the API keys to be URL-specific. The API key should only be accessible from the specified URLs. This means that even if a hacker gains access to your key, it should be rendered useless outside of the designated URLs. Additionally, implementing a secret manager can help you securely store, manage, retrieve, and rotate your application secrets efficiently.
There are several secret manager service providers available, such as Azure Key Vault, Google Cloud Secret Manager, AWS Secrets Manager, etc.
JavaScript files are considered valuable assets in modern web applications. Developers may inadvertently include sensitive information, such as API keys and database connection details, within client-side scripts. Consequently, it is vital to conduct thorough checks for any confidential data or secrets within JavaScript files.
Blog By
M Mohamed Swalih Moopen
Author
Arnab Chattopadhayay, Joy Sen
Assisted
About FireCompass:
FireCompass is a SaaS platform for Continuous Automated Pen Testing, Red Teaming and External Attack Surface Management (EASM). FireCompass continuously indexes and monitors the deep, dark and surface webs using nation-state grade reconnaissance techniques. The platform automatically discovers an organization’s digital attack surface and launches multi-stage safe attacks, mimicking a real attacker, to help identify breach and attack paths that are otherwise missed out by conventional tools.
Feel free to get in touch with us to get a better view of your attack surface.
