Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This is a new template to hunt for webpack source maps. #9519

Merged

Conversation

Lucky-Pulse
Copy link
Contributor

Template / PR Information

This is a new template to hunt for webpack source maps. It replaces the PR 9290 which I closed.
This one takes a completely different approach, running headless to access a browser.

What the JS does:

During testing of this template sites were discovered which loaded scripts, processed them and removed them from DOM, to accommodate this the JS accesses window.performance to grab scripts which were loaded (through script or fetch) but are no longer part of the DOM.

Then the DOM is queried for scripts with a src element as well as links that are loaded as script.
A delay was used, rather than waitload because during testing sites were encountered that take 10-15 minutes for the document.readyState to be complete, but set the DOM document.readyState to interactive well before being complete.

Finally, the results are returned to the template as an array of unique values.

The potential script URI are then retrieved to see if the response contains a sourceMappingURL, either a link or Base64, a header directing to a source map, or if a sourcemapconsumer is present.

For each script that contains a sourceMappingURL link, the link is retrieved (as a relative, absolute, root relative and scheme relative) to verify it is a valid sourcemap file.

Template Validation

I've validated this template locally?

  • YES
  • NO

Additional Details (leave it blank if not applicable)

Additional References:

@GeorginaReeder
Copy link

Thanks for this pull request @Lucky-Pulse , we appreciate it!

Copy link
Member

@tarunKoyalwar tarunKoyalwar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm !

Review Notes

  • We identify potential URLs for sourcemaps by fetching all JavaScript files that were explicitly requested and others. This includes scripts, inline JavaScript, and JavaScript files linked in HTML elements.
  • These potential URLs are deduplicated and fetched to load their associated sourcemap URLs. We do this by searching for the #sourceMappingURL and other locations that contain the actual URL to the sourcemap, such as headers. This method allows us to effectively handle cross-domain sourcemaps.
  • After retrieving these sourcemap URLs, we account for their potential variations using regular expressions. These variations can include relative paths, absolute paths, and more. We then request the final sourcemap URL and validate the response.

Known Issues / Considerations

  • Potential URLs can include third-party URLs like Google or Facebook, which are not related to the site and are also crawled. This is a limitation of the method, and currently, there is no easy way to filter out third-party URLs.
  • Handling relative and absolute URLs is beneficial, but it requires proper URL helper functions that are not available in DSL yet. This can lead to the formation of invalid domains, as shown in the following error message:
Could not execute step: [:RUNTIME] got following errors while executing flow <- [:RUNTIME] failed to execute http:fetch_absolute_srcmap protocol <- [http:RUNTIME] failed to parse url /static/master/7421/assets/build/js/chunks/6bbc38f7b56ecb.js.map while creating http request; [:RUNTIME] failed to execute http:fetch_noscheme_srcmaps protocol <- [:RUNTIME] got err while executing <https://https/static/master/7421/assets/build/js/chunks/6bbc38f7b56ecb.js.map> <- context deadline exceeded; [:RUNTIME] failed to execute http:fetch_root_relative_srcmap protocol <- [:RUNTIME] got err while executing <https://atl-global.atlassian.comatl-global-2.219.0.min.js.map> <- GET <https://atl-global.atlassian.comatl-global-2.219.0.min.js.map> giving up after 2 attempts: Get "<https://atl-global.atlassian.comatl-global-2.219.0.min.js.map>": no address found for host

  • This template is not fast because some components can be sent in parallel, which is not supported in Nuclei yet.

Example usage

$ ./nuclei -u https://bitbucket.org -headless -t a.yaml -v  

@Lucky-Pulse, thank you for your contribution and the time you invested in researching and adding this excellent template. The review process was lengthy because this template is unique and similar to an approach we had tried in Katana, as seen in this pull request: projectdiscovery/katana#413. This feature is a perfect fit for Katana compared to Nuclei, as it involves parsing and scanning for secrets in unminified JavaScript. However, the Katana pull request was closed due to known issues (highlighted in the above comments) until we can better address and resolve these challenges.

Overall, I think that this template is ready for use, provided that it is not included in the default run. This is because, while the template is innovative and experimental, it also has known issues and limitations due to the current features of Nuclei. (cc: @princechaddha )

@Lucky-Pulse, I personally believe this template is more suited for workflows (not the current one). Therefore, we will try to revisit and improve this template once we reinvent workflows, which we plan to do in the near future.

@princechaddha princechaddha added the Done Ready to merge label Jun 2, 2024
@princechaddha princechaddha self-assigned this Jun 2, 2024
@princechaddha princechaddha merged commit 693cda6 into projectdiscovery:main Jun 2, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Done Ready to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants