-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
This is a new template to hunt for webpack source maps. #9519
Conversation
Thanks for this pull request @Lucky-Pulse , we appreciate it! |
There was a problem hiding this 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.
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.
Source map consumer/generator: https://github.com/mozilla/source-map
Inline Sourcemaps: https://survivejs.com/webpack/building/source-maps/
SourceMap headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/SourceMap
Template Validation
I've validated this template locally?
Additional Details (leave it blank if not applicable)
Additional References: